Fix permanent UI freeze from off-EDT JsonResponseView.setEditorContent - #901
Open
adityaanikam wants to merge 1 commit into
Open
Fix permanent UI freeze from off-EDT JsonResponseView.setEditorContent#901adityaanikam wants to merge 1 commit into
adityaanikam wants to merge 1 commit into
Conversation
JsonResponseView.propertyChange called setEditorContent directly on the RESPONSE_PROPERTY change, which fires from the request submit worker thread, not the EDT. setEditorContent mutates the RSyntaxDocument via JTextComponent.setText, which violates Swing's single-thread rule. This produces a classic AB-BA deadlock when a response lands while the EDT is mid layout pass: the worker thread holds the document write lock and blocks trying to acquire the AWTTreeLock (via RUndoManager updating action enablement), while the EDT already holds the AWTTreeLock during validate and blocks waiting for the same document's read lock. Neither thread can proceed, and only killing the process recovers, as documented in the issue with a full thread dump. Deferred the setEditorContent call to SwingUtilities.invokeLater so the document is only ever mutated on the EDT, removing the cross-thread lock contention entirely. The updatingRequest reentrancy guard is left exactly where it was, set synchronously on the calling thread around scheduling the update, not around running it. Verified by tracing the exact lock chain in the issue's thread dump against current source and by compiling soapui/src/main/java cleanly with mvn compile. This is a Swing threading fix, not something a unit test can reasonably exercise given the race is timing dependent. Fixes SmartBear#898
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fixes #898
JsonResponseView.propertyChange called setEditorContent directly on the RESPONSE_PROPERTY change, which fires from the request submit worker thread, not the EDT. setEditorContent mutates the RSyntaxDocument via JTextComponent.setText, which violates Swing's single-thread rule.
This produces a classic AB-BA deadlock when a response lands while the EDT is mid layout pass: the worker thread holds the document write lock and blocks trying to acquire the AWTTreeLock (via RUndoManager updating action enablement), while the EDT already holds the AWTTreeLock during validate and blocks waiting for the same document's read lock. Neither thread can proceed, and only killing the process recovers, exactly as documented in the issue with a full thread dump.
Deferred the setEditorContent call to SwingUtilities.invokeLater so the document is only ever mutated on the EDT, removing the cross-thread lock contention entirely. The updatingRequest reentrancy guard is left exactly where it was, set synchronously on the calling thread around scheduling the update, not around running it.
Verified by tracing the exact lock chain in the issue thread dump against current source and by compiling soapui/src/main/java cleanly with mvn compile. This is a Swing threading fix, not something a unit test can reasonably exercise given the race is timing dependent.