Execute asynchronous actions in daemons #41
Labels
enhancement
RFE, feature
Comments
praiskup
added a commit
that referenced
this issue
May 27, 2020
As long as the configured cmd_* scripting is "atomic", we may be sure that we don't leave any leftover releases in inconsistent state. But when we **restart** the server when it is executing something by any background worker, the worker gets killed as well as the server and the resource might never be flipped back to a "consistent" UP state. Since the resources are meant to disposable, and it should be OK to re-run the cmd_delete command multiple times - rather request a termination of all the inconsistent resources when server starts. It would be nice to have nicer solution to #41 to avoid resource wasting, but this patch fixes the most problems. Relates: #41
praiskup
added a commit
that referenced
this issue
May 27, 2020
As long as the configured cmd_* scripting is "atomic", we may be sure that we don't leave any leftover releases in inconsistent state. But when we **restart** the server when it is executing something by any background worker, the worker gets killed as well as the server and the resource might never be flipped back to a "consistent" UP state. Since the resources are meant to disposable, and it should be OK to re-run the cmd_delete command multiple times - rather request a termination of all the inconsistent resources when server starts. It would be nice to have nicer solution to #41 to avoid resource wasting, but this patch fixes the most problems. Relates: #41
praiskup
added a commit
that referenced
this issue
May 27, 2020
As long as the configured cmd_* scripting is "atomic", we may be sure that we don't leave any leftover releases in inconsistent state. But when we **restart** the server when it is executing something by any background worker, the worker gets killed as well as the server and the resource might never be flipped back to a "consistent" UP state. Since the resources are meant to disposable, and it should be OK to re-run the cmd_delete command multiple times - rather request a termination of all the inconsistent resources when server starts. It would be nice to have nicer solution to #41 to avoid resource wasting, but this patch fixes the most problems. Relates: #41
praiskup
added a commit
that referenced
this issue
Jun 2, 2020
As long as the configured cmd_* scripting is "atomic", we may be sure that we don't leave any leftover releases in inconsistent state. But when we **restart** the server when it is executing something by any background worker, the worker gets killed as well as the server and the resource might never be flipped back to a "consistent" UP state. Since the resources are meant to disposable, and it should be OK to re-run the cmd_delete command multiple times - rather request a termination of all the inconsistent resources when server starts. It would be nice to have nicer solution to #41 to avoid resource wasting, but this patch fixes the most problems. Relates: #41
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
AllocWorker, TerminationWorker, etc. are run in background using
threads. It means that restart of whole resalloc server terminates
the background threads, too - which means that the database can
be inconsistent after resalloc server restart.
Typically it means that some resources are
STARTINGorDELETING, even though nothing happens with them.The text was updated successfully, but these errors were encountered: