There seems to be a bug in org.jboss.invocation.InvokerInterceptor.isLocal(Invocation). Or at least I am unable to figure out how naming lookups from one JBoss instance to another are supposed to work with this code in InvokerInterceptor:

public boolean isLocal(Invocation invocation)
{
return localInvoker != null && Registry.lookup(invocation.getObjectName()) != null;
}

When NamingServer is bound in Registry in all instances with the same id:

14:17:59,704 DEBUG [HttpProxyFactory] Created HttpInvokerProxy for invoker=jboss:service=Naming, nameHash=349114835

And when cluster B tries to look up cluster A's naming server in order to find the session bean for which it works as a delegate, Registry always finds the naming server which exists in cluster B with the same id.

Working code from 3.2.5 InvokerInterceptor:

public boolean isLocal()
{
return invokerID.equals(Invoker.ID);
}

I'll write my own implementation of InvokerInterceptor for use in delegate bean lookups, and a LocalInvoker which sets local invoker instance in this custom InvokerInterceptor instance. What I would like to know is am I right, whether what I found is a bug, should I report it, and is there possible problems with reverting to 3.2.5 behaviour for InvokerInterceptor.isLocal().

I see, thanks. I should have found this duplication bug which is marked for 3.2.7: http://jira.jboss.com/jira/browse/JBAS-1495

Well, served as a crash course to the JBoss remote invocation stack.