3 Replies Latest reply on Mar 26, 2007 3:41 PM by brian.stansberry

    SFSB proxy creation process incorrectly routed locally

    brian.stansberry

      Related discussions:
      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101220
      http://jira.jboss.com/jira/browse/EJBTHREE-773

      Problem I found while testing my EJBTHREE-881 fix:

      Say you have two completely unrelated SFSBs, Bean0 and Bean1, deployed on two different servers, node0 and node1. The only common point between Bean0 and Bean1 is they both are bound in JNDI under "StatefulBeanRemote". Otherwise they are completely unrelated.

      Client on node0 then contacts the JNDI server on node1 and does a lookup of "StatefulBeanRemote" expecting to get a proxy for Bean1. The SFSB proxy-creation process will end up being routed locally to the proxy factory for Bean0. Wrong!

      Problem is this:

      1) When client does an SFSB lookup, they don't directly download the SFSB proxy. Instead they download a proxy to the bean's ProxyFactory. That proxy then makes a remoting RPC back to the remote server to get the SFSB proxy. See o.j.ejb3.JndiProxyFactory.

      2) The proxy to the remote ProxyFactory includes o.j.aspects.remoting.IsLocalnterceptor. That interceptor will bypass the remote call and invoke locally if the aop Dispatcher has a target registered with the same id as the target id associated with the call.

      3) For calls made by the proxy to the remote ProxyFactory, the target id is the jndiName of the bean (plus a constant). So, if an unrelated target is registered locally with the same JNDI name, there's going to be confusion.

        • 1. Re: SFSB proxy creation process incorrectly routed locally
          brian.stansberry

          One possible solution -- the target id for the ProxyFactory can't be its JNDI name. It should be the ObjectName of the container + another attribute. For clustered beans, the partition name should be included as well.

          Problem with this is the doesn't deal with the EJBTHREE-773 issue -- apparently customers wanted to deploy the same bean in the same package on node0 and node1. But if a client on node0 specifically looks up the bean on node1's JNDI, the call should go to the node1 bean.

          • 2. Re: SFSB proxy creation process incorrectly routed locally
            brian.stansberry

            JIRA for this is http://jira.jboss.com/jira/browse/EJBTHREE-925.

            A fix that will give behavior consistent with the objective of EJBTHREE-773 is:

            1) For clustered SFSBs, the StatefulClusterProxyFactory should be registered with the Dispatcher with a name like this:

            container.getObjectName().getCanonicalName() + ",element=ProxyFactory,partition=" + container.getPartitionName()


            With this, the call to the proxy factory will route locally if the target factory is associated with the same bean name in the same deployment package in the same cluster partition; otherwise it will go remote.

            2) For non-clustered SFSBs, use of different partition names is not available as a means to distinguish two identical deployments on separate groups of servers. The stated objective of EJBTHREE-773 was to have the call go remote if this kind of deployment exists and the client does a lookup on a remote server, so:

            a) The client interceptor stack for the ProxyFactory proxy will not include the o.j.aspects.IsLocalInterceptor. This should be fine. For this call there are no later client-side interceptors that should be bypassed if the call is local. And Remoting already detects if the call's InvokerLocator points to a local server, and bypasses any marshalling if it is. So, getting rid of this interceptor allows calls to go remote but shouldn't noticeably the handling of legitimate local calls.

            b) the StatefulRemoteProxyFactory will be registered with the Dispatcher with a name like the above, minus the partition attribute. Given a) above this isn't really necessary, but it seems like a safer name (e.g. if someone some day restores the IsLocalInterceptor you won't end up with proxy creation calls going to completely unrelated beans.)


            I've implented the above on my Branch_4_2 working copy and the tests I wrote that surfaced this now pass. I'm running the full ejb3 testsuite overnight; if no issues pop up I'll check it in in the morning.

            • 3. Re: SFSB proxy creation process incorrectly routed locally
              brian.stansberry

              Went away from the non-clustered approach described in 2a) above to use a new IsLocalProxyFactoryInterceptor that only routes locally if the interceptor was created locally (analogue to the interceptor used for routing actual bean invocations.)