Bugs item #775600, was opened at 2003-07-22 05:20 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=775600&group_id=22866
Category: JBossServer Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Scott M Stark (starksm) Summary: corruption from duplicate jndi names Initial Comment: There is a bug in the interaction between the EjbModule and Container classes of org.jboss.ejb and the ServiceController that will corrupt existing services and mbeans if deployment is attempted of a different jar file containing a duplicate jndi name. The Problem: Container instances belonging to an EjbModule instance represent ejb's from the deployment descriptors. The Containers are registered as mbeans and JBoss services using a jmx object name of 'jboss.j2ee:jndiName=myJndiName,service=EJB'. If a second ejb jar is deployed containing a bean whose jndi name duplicates an existing one, then we have two Containers using the same jmx object name. Attempting to register a second mbean with this name produces an InstanceAlreadyExistsException, which is caught by EjbModule.createService() in the second deployment. The duplication is detected and rejected, deployment of the second jar fails. This is appropriate behavior, so far. The problem occurs during exception handling. The catch block in EjbModule.createService() calls destroyService() which asks the service controller to destroy and remove each of the module's Container instances. This request uses the Container's jmx object name, 'jboss.j2ee:jndiName=myJndiName,service=EJB'. The service controller is happy to comply, it proceeds to destroy and remove the service associated with the first deployment, leaving the first deployment in a corrupted state. Cleanup from the second EjbModule.createService () destroys services belonging to first. The core problem is that the EjbModule.destroyService() assumes that each Container has been properly constructed. When construction is interrupted, destruction should be bypassed. This problem can be recreated by making a copy of any ejb jar file and changing the jar file name. Deploy the original jar, then the duplicate. When the duplicate jar is deployed, the beans representing the original jar will be corrupted. The Patch: The EjbModule.destroyService() method needs to check the state of each Container prior to attempting to destroy or remove it. Unfortunately, the state that Container inherits from ServiceMBeanSupport is initialized to STOPPED, so it is impossible to use this state to distinguish between a Container whose creation was interrupted and one which was created, started and stopped in a normal lifecycle. Since the Container class has this additional lifecycle stage, outside of the normal service lifecycle, this Container patch file adds a separate boolean flag to the Container class, along with a package-protected accessor to test it's value. This flag is initialized to false and set to true at the end of Container.createService(). This EjbModule patch file changes the destroyService() method to skip all processing for any Container for which the new Container accessor method returns false. In the long run, a cleaner solution might be to add a new state to ServiceMBean to represent the stage between invocation of constructor and createService. This a more significant refactoring that potentially touches many more classes than this simple patch. It may not be worth the trouble if this type of issue is unique to ejbs. ---------------------------------------------------------------------- >Comment By: Scott M Stark (starksm) Date: 2003-07-22 06:20 Message: Logged In: YES user_id=175228 ServiceMBeanSupport initializes its state ivar to UNREGISTERED so effectively its its ctor state: /** The current state this service is in. */ private int state = UNREGISTERED; Completion of the postRegister JMX callback advances the state to REGISTERED. ---------------------------------------------------------------------- Comment By: Rod Burgett (rodburgett) Date: 2003-07-22 06:13 Message: Logged In: YES user_id=681969 I wasn't sure exactly what UNREGISTERED was to represent, what triggers a service into that state. From what I see, there is no initializer in ServiceMBeanSupport for state, so it gets a 0, i.e. STOPPED. Maybe I'm looking at stale code. Thanks. ---------------------------------------------------------------------- Comment By: Scott M Stark (starksm) Date: 2003-07-22 06:04 Message: Logged In: YES user_id=175228 The initial state as of 3.2.2RC2 is now UNREGISTERED so one can distinguish between a newly created service and one that has been stopped. I'll look at the patch in this context. ---------------------------------------------------------------------- Comment By: Rod Burgett (rodburgett) Date: 2003-07-22 05:22 Message: Logged In: YES user_id=681969 attaching the second diff file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=775600&group_id=22866 ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development