]
Brian Stansberry updated JBAS-4505:
-----------------------------------
Fix Version/s: Backlog
Inter-jar dependencies between clustered EJBs leads to bean not
accepting requests
----------------------------------------------------------------------------------
Key: JBAS-4505
URL:
https://jira.jboss.org/jira/browse/JBAS-4505
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering, EJB2
Affects Versions: JBossAS-4.2.0.GA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: Backlog
Scenario: 2 clustered EJB2 beans, A and B, deployed in A.jar and B.jar. A declares a
dependency on B via a <depends> in jboss.xml. A.jar gets deployed before B.jar.
Problem: The latch in bean A's HATarget that allows invocations to reach the bean
never gets released. The bean is available in JNDI, but any thread that attempts to
invoke on it will block (forever) on the latch. The bean becomes a black hole for
threads.
Cause: ProxyFactoryHA registers a JMX NotificationListener to listen for a service
started event. Receipt of that event triggers release of the latch. Problem is it
listeners for the start of the EJB module (A.jar) rather than the target bean. Reason for
this is described in the ProxyFactoryHA.create() method:
// ************************************************************************
// NOTE: We could also subscribe for the container service events instead of the
// ejbModule service events. This problem comes from beans using other beans
// in the same ejbModule: we may receive an IllegalStateException thrown
// by the Container implementation. Using ejbModule events solve this
// problem.
// ************************************************************************
this.container.getServer ().
addNotificationListener (this.container.getEjbModule ().getServiceName (),
new ProxyFactoryHA.StateChangeListener (),
filter,
null);
My interpretation of the comment is that if you allow access to the bean before the
entire module is started, and the bean calls into a 2nd bean in the same module, then a
request could come it via the 1st bean that tries to prematurely access the 2nd bean.
Waiting for the entire module to start is intended to prevent this. The assumption here
is that all beans within the module will complete the start phase before the module
itself.
Problem is the depends element on a bean breaks this assumption. What happens is you get
the following start order:
A.jar
bean B
bean A
B.jar
Effect is the notification for A.jar start happens before the HATarget for bean A even
exists. The latch that A's HATarget later creates will thus never get released.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: