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
{{ message }}
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.
In case a DB Lock can't be obtained, e.g. because the database is in maintenance, the dblock.go utility can cause the process to exit. The process should not exit, but rather obtaining the lock should be retried.
hi, @beckermarc , after double check the db lock logic, I think the implementation is reasonable.
db_lock is a guard for all the other inner operation processes , i.e. metric db pruner, app sync and etc.
if operator A get the lock, then its inner processes start to work. Then, if A lost the lock due to any possible issue, B can take over to get the lock and start its operation processes.
To avoid the inner process in operation A to operation B to run in parallel , operator A must exit to terminate all its inner processes...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In case a DB Lock can't be obtained, e.g. because the database is in maintenance, the dblock.go utility can cause the process to exit. The process should not exit, but rather obtaining the lock should be retried.
See here for further details: https://github.com/cloudfoundry/app-autoscaler/blob/master/src/autoscaler/sync/dblock.go#L68
The text was updated successfully, but these errors were encountered: