Bug 1280507
Summary: | [GSS](6.4.z) Endpoint can be closed before doConnect tasks finished causing AbstractHandleableCloseable.close to wait forever | ||||||
---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Brad Maxwell <bmaxwell> | ||||
Component: | Remoting | Assignee: | Enrique Gonzalez Martinez <egonzale> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Peter Mackay <pmackay> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 6.4.5 | CC: | aogburn, bbaranow, bmaxwell, cdewolf, clichybi, david.lloyd, dpospisi, egonzale, mnovak, myoshida, onagano, pmackay | ||||
Target Milestone: | CR1 | ||||||
Target Release: | EAP 6.4.8 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1297478 1316385 (view as bug list) | Environment: | |||||
Last Closed: | 2017-01-17 12:33:03 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: | 1278606 | ||||||
Bug Blocks: | 1279553, 1289243, 1297478, 1316385, 1329530 | ||||||
Attachments: |
|
Description
Brad Maxwell
2015-11-11 23:20:52 UTC
Hi Aaron: That stacktrace is different from the one in the description of this BZ (it is the one in BZ#1278606). This line: https://github.com/bmaxwell/jboss-remoting/blob/dfe063d954038f780026f58e540dfd64d614ae53/src/main/java/org/jboss/remoting3/EndpointImpl.java#L317 is causing the worker thread to get stuck in there because it tries to close the connection in a sync way. In spite the other end sends back the close signal it is never processed by the client side (that's the reason why removing the line makes remoting to process properly the sequence of closing the connection). From my point of view we should go back to the first bug and try to see the problem in there (naming component). PR upstream https://github.com/jboss-remoting/jboss-remoting/pull/56 PR 6.4.z: https://github.com/jboss-remoting/jboss-remoting/pull/57 Created attachment 1101716 [details]
Test project using EJB client
An EJB and its client is included. Remoting library is updated to 3.3.6.Final (EAP 6.4.5 equivalent).
Thread dumps and log file are included. There are 3 snapshots in breakpoints.jstack: at first break point, at second break point, and when the client hangs at close().
breakpoints.jstack
breakpoints.log
merged: https://github.com/jboss-remoting/jboss-remoting/commit/083c125bdcadd4b65da77ddafa1e71e5aa3dc8e0 Enrique González Martínez <elguardian> updated the status of jira JBEAP-2017 to Resolved Jason Greene <jason.greene> updated the status of jira JBEAP-2017 to Reopened the fix uncovered another issue in upstream; that's the reason why it was reopened. https://issues.jboss.org/browse/REM3-216 Another fix was pushed in 3.3.x branch. see https://bugzilla.redhat.com/show_bug.cgi?id=1289243#c1 That commmit is related to REM3-216, but for some reason the integration test still hangs sometimes (I wasn't able to reproduce the problem so far) This let 7.0.0 and 6.4.z out of sync as the issue in upstream was moved to 7.0.z PS: The fix is still in the branch so current status of this BZ is not matching the PR state. I don't think we have a procedure for these cases. I missed the right link. The uncovered bug is this one: https://issues.jboss.org/browse/REM3-221 Bartosz Baranowski <bbaranow> updated the status of jira JBEAP-2017 to Resolved Ladislav Thon <lthon> updated the status of jira JBEAP-2017 to Reopened Verified with EAP 6.4.8.CP.CR2 Enrique González Martínez <elguardian> updated the status of jira JBEAP-2017 to Resolved Enrique González Martínez <elguardian> updated the status of jira JBEAP-2017 to Resolved Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. |