Bug 989879
Summary: | (6.4.z) NotOpenException: Cannot open new channel because close was initiated on server shutdown | ||
---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Jitka Kozana <jkudrnac> |
Component: | EJB | Assignee: | Radovan STANCEL <rstancel> |
Status: | CLOSED WONTFIX | QA Contact: | Michal Vinkler <mvinkler> |
Severity: | unspecified | Docs Contact: | Russell Dickenson <rdickens> |
Priority: | unspecified | ||
Version: | 6.1.1 | CC: | bbaranow, bmaxwell, cdewolf, egonzale, jmartisk, rstancel |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-07-21 16:41:15 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: |
Description
Jitka Kozana
2013-07-30 06:23:20 UTC
Assigning jpai EJB issues to david.lloyd. Please re-assign to Cheng or others as needed. From what I see in the logs, I'm not sure if this is actually an error. The client tries an invocation and picks a cluster node which is shutting down at that moment. The outbound remoting channel to that node gets closed in the meantime, so remoting tries to re-create it, but it fails because the server refuses it. The client logs an error and then picks another node. The EJB invocation proceeds correctly, doesn't it? I don't see any error message suggesting that the invocation failed. Or am I mistaken? Hi Jan. From my point of view this is a bug. What is happening here is the following: 1) One end close the connection (the shutdown of the connection starts) 2) the other end detects the broken channel and registers a reconnect handler. 3) The ConnectionPool class inside the ejb client has two ways of removing connection from the cache a) through close listener in the connection pool https://github.com/elguardian/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/remoting/ConnectionPool.java#L273 b) through the release operation: through close listener in the connection pool https://github.com/elguardian/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/remoting/ConnectionPool.java#L92 These two ways are not thread safe. The attempt to reconnect happens before the 3.a (through the broken channel event). This race condition leads to a situation where the ConnectionPool returns a connection is going to be closed. For avoiding this situation the reconnect handler needs to ensure that is executed *only* after the connection has been closed. This mean serialize the events. Whenever the connection is broken, add a close listener to the channel for registering the reconnect handler. This ensure the events are sequential (it's not going to happen that a close channel tries to reconnect till the connection is cleaned up) avoiding the situation of a closing connection. I added the solution for this in another BZ#1020074 (ejb async reconnection) https://github.com/elguardian/jboss-ejb-client/blob/44982ae7a5e19c76ad96040dccddff8cfee2f265/src/main/java/org/jboss/ejb/client/EJBClientContext.java#L565 commit from BZ#1020074 was reverted. creating a new upstream jira for this issue. component upstream merged: https://github.com/jbossas/jboss-ejb-client/pull/112 reverted in upstream. https://github.com/jbossas/jboss-ejb-client/pull/115 |