You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no way to ensure only N of M servers running the same process restart after a config change concurrently.
There is a splay option to add a random delay which can partially address this issue, but randomness is a part of it and it is ill suited to processes that are slow to start.
As mentioned in #53 using a Consul lock could be used to implement this reliably with the lock needing to be acquired before the process is restarted (the lock would not be used during startup, only during a restart/reload after config change).
The lock should be combined with a fixed timeout (at a minimum as a failover, but also in case there isn't any good way to signal that the service is "ready") combined optionally with other checks such as that the process has started listening on a certain port, or looking for a certain stdout/stderr line. Perhaps Consul's own service health checking could be utilised in some fashion to signal this. This would be a once off check to release the lock (unless the timeout happens first).
The text was updated successfully, but these errors were encountered:
Currently there is no way to ensure only N of M servers running the same process restart after a config change concurrently.
There is a splay option to add a random delay which can partially address this issue, but randomness is a part of it and it is ill suited to processes that are slow to start.
As mentioned in #53 using a Consul lock could be used to implement this reliably with the lock needing to be acquired before the process is restarted (the lock would not be used during startup, only during a restart/reload after config change).
The lock should be combined with a fixed timeout (at a minimum as a failover, but also in case there isn't any good way to signal that the service is "ready") combined optionally with other checks such as that the process has started listening on a certain port, or looking for a certain stdout/stderr line. Perhaps Consul's own service health checking could be utilised in some fashion to signal this. This would be a once off check to release the lock (unless the timeout happens first).
The text was updated successfully, but these errors were encountered: