[bdecoste]

Optimizing for local calls is huge - avoiding the rmi call stack and the serialization is orders of magnitude faster.

What if we went back to the original isLocalInterceptor mechanism and didn't use the ejbName to determine whether the bean was local? (we did the lookup in the EJB3Registry based on a unique name, so the isLocal() test would not get confused between a local instance of a bean vs a remote instance. The proxy has the container object name - what if we made that unique (add a VM specific or timestamp as a parameter of the container object name)??

[brian.stansberry]

You need something to identify the cluster-wide deployment, as opposed to the VM. The current isLocal() approach distinguishes the VM just fine and allows the call to go remote. Where it fails is in properly letting the call stay local.

To recognize each other the deserialized proxy and the local container need a common piece of info.

Perhaps including the partitionName is sufficient. If someone:

1) Creates cluster A and names it DefaultPartition.
2) Creates cluster B and names it DefaultPartition.
3) Deploys things that have the same ejbName on both.
4) Has a client on A that downloads a proxy from B and invokes on it.

Well, that's just stupid. They should just use different partition names. If they want that to work they can remove the IsLocalInterceptor or write a custom impl.

Re the benefits of optimizing, I 99% agree. The only area where I'm unconvinced is SFSB where the proxy wasn't created locally (a .01% case). But that's such an edge case that I don't really care. :) And it's too late to change FirstAvailable for 4.2 to properly support it anyway.

[bill.burke]

remember you could have a IsLocalInterceptor and a ClusteredIsLocalInterceptor if that's the approach you decide.

[brian.stansberry]

Back to this; time to get it done.

To recognize each other the deserialized proxy and the local container need a common piece of info.

Perhaps including the partitionName is sufficient.

Including the partitionName in the container OID/ObjectName won't work, as the ObjectName is created in the EJBContainer c'tor, before any the value of any @Clustered annotation or xml config is available.

So, that means the partition name needs to be independently stored in the proxy and the EJBContainer. This means adding a partitionName field to the clustered proxy classes and to EJBContainer, and adding logic to EJBContainer.start() to resolve any @Clustered annotation.

I'll add a ClusteredIsLocalInterceptor which tries to match up the proxy with the container, routing the call locally if there's a local bean from the same partition.

Any objections to this?

[bdecoste]

No objections here

[jahlborn]

just wanted to point out some code i posted a while ago to deal with this issue.

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991990

[brian.stansberry]

Thanks, James.

The problem with storing the partition name in the interceptor is you are forced to use a static method to determine the partition name. That limits you to a single partition per VM, while JBoss AS supports multiple partitions.

I ended up including the partition name in the proxy rather than in an interceptor; it gets passed to the interceptor as invocation metadata. The EJB container is responsible for creating the proxy and can pass the the partition name as a c'tor arg without any problem, so there's no need for a static method.