I have a partial answer to the question which goes back to the way this code has been implemented. The server code that I'm dealing with has a single 'Portal' bean that serves up access to all the other beans in the system. This means that single Portal bean is creating the other beans within the context of the server. The relevant jboss clustering docs say:
"On the server side, new InitialContext(), will be bound to a local-only, non-cluster-wide JNDI Context(this is actually basic JNDI). So, all EJB homes and such will not be bound to the cluster-wide JNDI Context, but rather, each home will be bound into the local JNDI."
JBossClustering.pdf, pg 16
Now while this answers why most of the beans are not getting created in a roundrobin fashion it does not answer why the 'Portal' bean itself is always being created on the same machine.
The client code gets the naming context once:
InitialContext jndiContext = new InitialContext(properties);
and then for each 'test user' after that it does:
Object ref = jndiContext.lookup("middleware/Portal");
PortalHome home = (PortalHome) PortableRemoteObject.narrow(ref, PortalHome.class);
Portal portal = home.create(portalSpec, clientSpec);
Please correct me if I'm wrong but it is the 'lookup("middleware/Portal")' method call that should be alternating the creation of the Portal bean between the two clustered jbosses that I have setup.
Is there a way I can look at the stub for the Portal bean that is being created to learn some information? I'm at the point where I running out of questions to ask to solve the problem.
Again, thoughts and opinions are welcome.
Can you show us the code that actually create the JNDI context, create the SFSB and makes invocation against it?
Depending on your LB policy for your home and when you (re-)create your home, the behaviour may be what you actually see. This is by design.
Some of this behaviour has been changed in 3.2+. Could you please make a test with 3.2 (jboss-3.2 from Branch_3_2) and see if it better fits your needs?