Behavior difference in intra-AS EJB calls

[brian.stansberry]

An FYI; not necessarily a problem.

I'm seeing a difference in behavior when a bean in one AS looks up a bean in another AS and then invokes on it.[1] Previously that call would go remote; now it stays local if the same bean is deployed locally.

This is because of the change in how proxy factories are created. Previously they were built on the server and downloaded. Now they are built on the client. Effect is IsLocalProxyFactoryInterceptor.isLocal() will *always* return true.

I don't know if this is an acceptable behavior change or not. I do think it should be overridable; for EJB2 beans I often see forum requests wanting to know how to override "local-preference". For EJB2 this can be overridden by writing a simple custom extension of a JBoss class, which can then be configured in on a per-bean basis. For EJB3 the equivalent override would be a bit more complex (customized IsLocalProxyFactoryInterceptor and extension of all the ObjectFactory impls to override createProxyFactoryProxy). But if that's done I don't see any way to configure the new classes on a per-bean basis. The JndiSessionRegistrarBase impls to use are hard coded.


[1] e.g.

 public VMID getVMIDFromRemoteLookup(String jndiURL, String name)
 throws NamingException
 {
 log.info("Looking up " + jndiURL + "/" + name);
 Properties env = new Properties();
 env.setProperty(Context.PROVIDER_URL, jndiURL);
 env.setProperty("jnp.disableDiscovery", "true");
 InitialContext ctx = new InitialContext(env);
 VMTester tester = (VMTester) ctx.lookup(name);
 return tester.getVMID();
 }

[brian.stansberry]

The old behavior could be restored easily enough by adding a StringRefAddr with some sort of vmid/long to the Reference. Then the ObjectFactory uses a constructor method on IsLocalProxyFactoryInterceptor that gets passed the vmid. Or a factory method on IsLocalProxyFactoryInterceptor that returns a 'singleton', either IsLocalProxyFactoryInterceptor.local or IsLocalProxyFactoryInterceptor.remote.

If you guys think that's a valid thing to do, I can do it pretty quick; an existing clustering test already tests this.

[brian.stansberry]

Just to clarify; my initial post was inaccurate.

Issue is with the proxy to the proxy factory that is created client-side via ProxyObjectFactory.createProxyFactoryProxy(). That results in a proxy that uses an IsLocalProxyFactoryInterceptor that is instantiated client-side.

[alrubinger]

Some more clarification (and also for the record so I can remember):

Proxy Factories are created on the server and registered with MC (and, if remote, with Dispatcher).

Remote JNDI lookups create a PojiProxy to the Dispatcher to get at the Proxy Factory, calling upon it to return the Proxy.

S,
ALR

[wolfc]

A bean that has been looked up remotely, but that also exists locally should not be invoked locally. (Where local and remote are nodes which are not bound in the same cluster.)

https://jira.jboss.org/jira/browse/EJBTHREE-773

[brian.stansberry]

"wolfc" wrote:
A bean that has been looked up remotely, but that also exists locally should not be invoked locally. (Where local and remote are nodes which are not bound in the same cluster.)

The behavior you describe is what existed for clustered beans looked up from a remote node: same cluster, go local, different cluster, go remote. I can reproduce that behavior with no problem w/ proxy-clustered.

What's changed is the behavior of non-clustered beans -- before they went remote, now they go local. I found the threads related to EJBTHREE-773, and it's clear from those that the intent of Bill D's work was that the calls would go remote:

http://www.jboss.com/?module=bb&op=viewtopic&t=104924
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101220