-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFLY-2741] Single process management operation timeouts #6206
Conversation
Build 3507 is now running using a merge of a4bb5d7 |
Build 3507 outcome was FAILURE using a merge of a4bb5d7 Build problems:Failed tests detected
Failed tests
|
retest this please |
Build 3526 is now running using a merge of a4bb5d7 |
Build 3526 outcome was FAILURE using a merge of a4bb5d7 Build problems:Failed tests detected
Failed tests
|
Closing while I sort the manualmode tests. |
Build 3567 is now running using a merge of e4b1bd6 |
Build 3568 is now running using a merge of 4472fb0 |
Build 3568 outcome was SUCCESS using a merge of 4472fb0 |
Build 3572 is now running using a merge of 34a72a3 |
Build 3572 outcome was SUCCESS using a merge of 34a72a3 |
Superseded by #6237 |
Limit the time operation execution can block in various places, 300 secs by default, with the overall setting configurable via sys prop and the ability to override on a per-op basis using an operation header.
If an op times out, further blocking points during rollback will only wait 5 secs. Otherwise the various blocking points that come up could result in waiting 300 secs several more times, which IMO is excessive.
If the service container cannot reach stability by the time the op releases locks, the process is placed in restart-required state. Not reload-required as a reload does not result in a new service container.