See Thread at: http://www.techienuggets.com/Detail?tx=52347 Posted on behalf of a User I think you'll want to modify the EJB stack defined in server/all/deploy/ejb3-interceptors-aop.xml. You can add your custom interceptor or simply remove/comment-out the "IsLocal" interceptor. For example, if you want to make the change for clustered stateless session beans the applicable section could look like this: <stack name="ClusteredStatelessSessionClientInterceptors"> <!-- interceptor-ref name="org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor"/ --> <interceptor-ref name="org.jboss.aspects.security.SecurityClientInterceptor"/> <interceptor-ref name="org.jboss.aspects.tx.ClientTxPropagationInterceptor"/> <interceptor-ref name="org.jboss.aspects.remoting.ClusterChooserInterceptor"/> <interceptor-ref name="org.jboss.aspects.remoting.InvokeRemoteInterceptor"/> </stack> Notice the commented out ClusteredIsLocalInterceptor. I've been trying to do the exact same thing as you (i.e. cluster ejbs called from within the same JBoss 4.2.3 server). And I just figured this out today. I think it does what I want, but haven't fully "exercised" it in any way. Let me know if this helps. -Randy In Response To: Hi All, After much reading up, it appears that I need to write a custom InvokerInterceptor to achieve clustering of Session beans in JBoss (I am running on 4.2.3) and I have a couple of questions before I venture down this road (although it is not a lot of code when looking at it) I have an application that runs entirely in the container, I no external client, the system is implemented in Sessions beans, Entity Beans, JMX MBeans and MDB Beans (it also has a minimal web client built on tapestry 5 for mainly management and configuration tasks), all in EJB3, and is a fairly highly stressed system which has become cpu bound, hence we are looking at gaining a performance increase by clustering. As the application is fully contained within the container, we have the scenario where clients and session beans run in the same JVM (MDB's and JMX beans act as clients as well as session beans dependent on other session beans) so I predict a large performance increase by being able to load balance our session bean calls between multiple servers, however the limitation of the "optimization" where by the InvokerInterceptor routes calls to local instances only is a big limiting factor and does not allow us to distribute the load, hence looking at implementing a custom InvokerInterceptor. 1. When overriding hasLocalTarget and simply returning false, will the round robin process still send some requests to the "local" session bean instance as well as the "remote" instances in the cluster, or will it send ALL requests to the remote instances / nodes for processing and ignore the local instance all together? 2. If the answer to 1 is "Yes, it will send all requests to remote nodes" under the scenario of simply returning false, is the InvokerInterceptor "statefull". What i mean by this is would something like the following work: | public class CustomInvokerInterceptor extends InvokerInterceptor { | | private boolean _local = false; | | public boolean hasLocalTarget() { | if (_local) { | _local = false; | return true; | } else { | _local = true; | return false; | } | } | } | such that between calls to hasLocalTarget, the state of _local will be maintained, or will the be a fresh instantiation between invocations and thus always return false? If this is not the case and all calls end up going remote, we would essentially have an under utilised node on the cluster that simply acts as a client to the other nodes (I hate wasted resources :) ) 3. Based on the fact that there are a number of threads regarding this issue over some time now, is it still an issue? IE, in 4.2.3 or even 5, do we still need to implement a custom InvokerInterceptor to "de-optimize" JBoss so we can optimize out application, or has it now been made configurable such that we can change a config setting to tell the container that we want a certain behavior or some other way to achieve RoundRobin load balancing? I understand the fact that it is more resource intensive to route a call to a remote node when it could be serviced locally, but that rule doesn't cater very well for the scenario where the local node is 100% CPU stressed and an application has become CPU bound. Cheers, Ben