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
One thing that I noticed when trying this out is that during redeploy, we have to wait until the lock has timed out until the next single-beat process can pick up the slack. While I applaud the simplicity of this approach, this can be an issue for some deployments that use the locktime of 300 with an interval of 60 as suggested in the README.
Would it be feasible to have the current beat process on detecting a sigterm release the lock in Redis immediately after it is terminated?
The text was updated successfully, but these errors were encountered:
Also, one other usage question that is related to using this to achieve HA with celery-beat:
Wouldn't it be safer to wait until the child process has actually exited before exiting ourselves? And if the child is not responding, could we do a SIGKILL after a while?
First off, thanks! This works great.
One thing that I noticed when trying this out is that during redeploy, we have to wait until the lock has timed out until the next single-beat process can pick up the slack. While I applaud the simplicity of this approach, this can be an issue for some deployments that use the locktime of 300 with an interval of 60 as suggested in the README.
Would it be feasible to have the current beat process on detecting a sigterm release the lock in Redis immediately after it is terminated?
The text was updated successfully, but these errors were encountered: