Uploaded image for project: 'EJB 3.0'
  1. EJB 3.0
  2. EJBTHREE-1116

Clustered container sees requests during shutdown

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 1.0.0-Beta1
    • AS 4.2.2.GA
    • Clustering
    • None

      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.

        There are no Sub-Tasks for this issue.

            pferraro@redhat.com Paul Ferraro
            bstansbe@redhat.com Brian Stansberry
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: