Foxx in a cluster setup

The same considerations that apply to writing Foxx services for astandalone server also apply to writing services for a cluster:

You should avoid any kind of file system state beyond the deployed servicebundle itself. Don’t or encodeany expectations of the file system state other than the files in theservice folder that were installed as part of the service(e.g. don’t use file uploads or custom log files).

Additionally, special precautions need to be taken when using thedevelopment mode in a cluster.

• When installing, upgrading or replacing a service, the new service isextracted to a temporary directory where Foxx validates the manifest fileand parses the referenced scripts and main file.

• When replacing, upgrading or installing a service, the new service’s setupscript is executed in a single thread of the Coordinator as desired.

• The existing service is unloaded from the Coordinator’s worker threadsand the new service is reloaded. If the new service runs into an errorat this point, the service will be marked as broken andneeds to be replaced manually.

• The Coordinator triggers a local self-heal followed by triggeringa self-heal on all other Coordinators.

Note that this means that any service that passes the initial validation stepwill complete the install, upgrade or replace process, even if any of theconsecutive steps fail (e.g. due to a runtime error encountered while executingthe service’s main file or a syntax error in a required file not referencedfrom the manifest directly).