Upon further reading, it looks like this is exactly how HA-JNDI is supposed to behave, maybe I can get around this by implementing my own load balance policy, I'm going to give that a go.
Hmm, It appears that from within the same JVM that the LoadBalancePolicy is completely ignored, I can understand this from inside another bean, but should this always be the case? It would be nice to be able to control with the load balance policy whether the lookup uses the HA-JNDI policy or just always tries to find it locally.
I tried setting the Initial Context in my MBean like so:
InitialContext ic = new InitialContext(props);
In hopes that the "localhost:1100" would force the HA-JNDI stub to be returned. Does anyone have any suggestions on this?
The reason it behaves this way is that the HA-JNDI is for nothing in this. In fact, the it is the *invoker* that will see that the target is available locally and optimize the call directly. This is by design.
Maybe, the easiest thing to do for you would be to start another JBoss instance, remove almost *all* services from it and only keep you MBeans inside. As calls won't be able to be co-located, the load-balancing policy will work perfectly.
That's what I'll probably do, thanks.
I tried to call it from an "external" mbean in another JVM and I get an error saying that the ejb is not bound. However, when I run it from a standalone client, it works perfectly.
I set up the jboss instance with the mbean to be part of the cluster so (hopefully) it would realize that the bean was not available locally and do the lookup on the cluster, but it never does. It appears to not even try to look it up on the cluster.
I set up the second instance with the bare minumum and set the HA-JNDI port to 1111. Any help would be appreciated.
It works now. I must have had something set up wrong. Good enough for me, thanks for the suggestion.