ProxyFactory remains usable during SFSB container shutdown ---------------------------------------------------------- Key: EJBTHREE-1547 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1547 Project: EJB 3.0 Issue Type: Bug Components: core Affects Versions: 1.0.0-Beta5 Reporter: Brian Stansberry During a testing session with a service that was using 4 threads to continually create SFSBs, I attempted to undeploy the bean. Got log failures like the following: 18:56:20,638 ERROR [RegionManager] failed inactivating /sfsb/jar=andymiller-test.jar,name=SimpleAnnotationStatefulBean,service=EJB3 org.jboss.cache.CacheException: Region /sfsb/jar=andymiller-test.jar,name=SimpleAnnotationStatefulBean,service=EJB3 is already being activated/deactivated at org.jboss.cache.RegionManager.inactivateRegion(RegionManager.java:573) at org.jboss.cache.RegionManager.activateRegion(RegionManager.java:508) at org.jboss.cache.RegionManager.activate(RegionManager.java:376) at org.jboss.cache.RegionManager.activate(RegionManager.java:339) at org.jboss.cache.RegionImpl.activate(RegionImpl.java:82) at org.jboss.ejb3.cache.tree.StatefulTreeCache.start(StatefulTreeCache.java:358) at org.jboss.ejb3.stateful.StatefulContainer.createAndStartCache(StatefulContainer.java:302) at org.jboss.ejb3.stateful.StatefulContainer.getCache(StatefulContainer.java:340) at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:488) at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:550) at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296) at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160) at org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:133) at org.jboss.ejb3.proxy.clustered.objectfactory.session.stateful.StatefulSessionClusteredProxyObjectFactory.getProxy(StatefulSessionClusteredProxyObjectFactory.java:66) at org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:153) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1426) at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1443) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:797) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:661) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.ejb3.test.clusteredsession.SimpleAnnotationStatefulBeanUser$BeanCreator.run(SimpleAnnotationStatefulBeanUser.java:85) at java.lang.Thread.run(Thread.java:595) The at org.jboss.ejb3.cache.tree.StatefulTreeCache.start(StatefulTreeCache.java:358) at org.jboss.ejb3.stateful.StatefulContainer.createAndStartCache(StatefulContainer.java:302) logging shows container's 'cache' field has been nulled, so the request thread is trying to create and start a new cache. This then leads to conflicts at the JBC level, where the HDScanner thread is doing work to undeploy the old cache. Couple thoughts: 1) Is letting a request thread create/start the cache a good idea? Shouldn't this be limited to the start() sequence, with an ISE thrown if a request thread finds there is no cache? 2) Should we be adding something like the org.jboss.ejb3.BlockContainerShutdownInterceptor into this call stack to ensure we don't get race conditions like this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira