Clustered container sees requests during shutdown ------------------------------------------------- Key: EJBTHREE-1116 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1116 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123677 -- during undeploy the cache is being asked for beans after it has already gone into cleanup. It should not be exposed to requests at this point. A couple points: 1) StatefulContainer.stop() does this: if (cache != null) cache.stop(); super.stop(); Basically the cache is stopped before anything else. 2) The HA versions of the old detached invokers included this kind of logic in invoke(): HATarget target = (HATarget)beanMap.get(invocation.getObjectName()); if (!target.invocationsAllowed ()) throw new GenericClusteringException(GenericClusteringException.COMPLETED_NO, "invocations are currently not allowed on this target"); .... else continue on and handle call An HA proxy will catch the GenericClusteringException and fail over. There is no equivalent interceptor in EJB3. In the container stop() methods there is a usage of Dispatcher.singleton.unregisterTarget(...) which will lead to an exception being thrown if a call comes in for the container, and an HA proxy will catch that exception and fail over. So, adding an interceptor to check the HATarget *may* not be necessary, if we are sure that Dispatcher.singleton.unregisterTarget(...) is always called very early in the stop() process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira