OF-2921: Prevent deadlock by not broadcasting synchronously #2635
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a client drops offline, a presence update is broadcast on behalf of that client. We've observed deadlocks occurring when this happens (as the broadcast itself, especially when it occurs in context in of MUC rooms, will acquire mutexes). There appears to be little reason for this broadcast to happen synchronous to the process of session termination process. To reduce the likelihood of deadlocks, this commit makes the broadcast happen in an asynchronous process.
When stream management is enabled, deliver and record stanzas under a mutex. If it's not enabled, don't acquire the lock to reduce lock contention.
When a websocket error is raised while holding another mutex (eg: when processing a MUC stanza) then having _another_ mutex introduces a deadlock risk. This has been observed to happen in the wild. In this commit, the mutex held when processing a websocket error is removed.
guusdk
added
the
backport 4.9
|
IIRC, this was done synchronously due to issues we observed with remote MUC users in open_chat not seeing the shutdown when Ignite's Openfire was restarted. |
|
I don't quite recall that issue, but given that this introduces deadlocks (which causes the system to become unusable and throw out-of-memory exceptions, the cure might be worse than the ailment in this case. |
|
Agreed, I think this was https://igniterealtime.atlassian.net/browse/OF-1688 |
akrherz
approved these changes
Jan 4, 2025
|
Successfully created backport PR for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a client drops offline, a presence update is broadcast on behalf of that client. We've observed deadlocks occurring when this happens (as the broadcast itself, especially when it occurs in context in of MUC rooms, will acquire mutexes).
There appears to be little reason for this broadcast to happen synchronous to the process of session termination process. To reduce the likelihood of deadlocks, this commit makes the broadcast happen in an asynchronous process.