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

[Paul Ferraro (JIRA)]

     [ https://jira.jboss.org/jira/browse/EJBTHREE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved EJBTHREE-1116.
------------------------------------

    Resolution: Done


Leverage read-write lock to support clean startup/shutdown of an EJBContainer.
Write lock is acquired on create(), released after start(), and re-acquired on stop().
Read locks are acquired/released via interceptor early in the chain.

> Clustered container sees requests during shutdown
> -------------------------------------------------
>
>                 Key: EJBTHREE-1116
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1116
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.2.GA
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>             Fix For: AS 5.0.0.CR2
>
>         Attachments: ejb3-cluster-test.zip, Gate.java
>
>
> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira