[jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1116) Clustered container sees requests during shutdown

[Chris Meadows (JIRA)]

     [ http://jira.jboss.com/jira/browse/EJBTHREE-1116?page=all ]

Chris Meadows updated EJBTHREE-1116:
------------------------------------

    Attachment: ejb3-cluster-test.zip

Two node cluster for a SFSB that cycles over N states of a Persistable bean. 
Client starts M threads to cycle through the N states of M SFSBs

Start both servers and tail the logs. Wait til logs indicate both cluster members are serving requests, then gracefully stop one of trhe cluster members.
Client reports javax.ejb.NoSuchEJBException, Could not find stateful bean

> 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
>         Attachments: ejb3-cluster-test.zip
>
>
> 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