Bug 1215714
| Summary: | (6.4.z) Do not hold connection lock while closing channels | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Brad Maxwell <bmaxwell> |
| Component: | Remoting | Assignee: | David M. Lloyd <david.lloyd> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jitka Kozana <jkudrnac> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4.0 | CC: | bbaranow, cdewolf, joallen, lthon, rsvoboda |
| Target Milestone: | CR1 | ||
| Target Release: | EAP 6.4.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: JBoss remoting held onto a lock while closing connections for longer than needed.
Consequence: JBoss could experience a thread deadlock.
Fix: Change JBoss Remoting to not hold onto the connection lock while closing channels.
Result: The deadlock does not occur.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-17 10:13:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1199231, 1219165 | ||
|
Description
Brad Maxwell
2015-04-27 14:15:31 UTC
Please include more detailed description of the problem linked commit is solving. SET/GSS - please provide automated test (as discussed on triage) to increase CP throughput. I will qa_ack afterwards or when the scope of CP01 is clear and we have enough seats. Please include more detailed description of the problem which is soled by linked commit. FYI - there is no customer case attached to this BZ. *** Bug 1230067 has been marked as a duplicate of this bug. *** Verified with EAP 6.4.2.CP.CR1.
Note: I believe that there are still situations in which an exception during closing may cause a hang. E.g. the `closeAsync` method might be modified in the same way, and maybe it should. I posted a comment in the upstream JIRA (and if I get no reaction, I will open a new upstream JIRA).
That said, I also believe that the patches here _do_ fix a certain class of problems, hence VERIFIED.
Verification note: put `if (true) throw new RuntimeException("!TEST!");` at the beginning of org.jboss.remoting3.ConnectionImpl.closeAction to simulate a problem (it can't happen on this exact place normally, but it's a good enough approximation). Then, run a simple program that invokes a remote EJB. It hangs with Remoting 3.3.4 and it finishes successfully with Remoting 3.3.5. It's enough to change Remoting on the client, no need to change it on the server.
*** Bug 1248299 has been marked as a duplicate of this bug. *** Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. |