Your assumptions were almost correct. You forgot a very smiple design-decision that we made: everytime we can do in-VM call, we favor it and do not do remote invocations (optimisations). Consequently, as long as your SLSB is also deployed in the same JVM as your MDB, it will never round-robin. A flag will be present in future JBoss release (4.0 at least) to bypass this optimisation.
In the meantime, you can deploy two jboss instances on the same machine: one simply running the MDB and the other your applications with the SLSB.
ooooh, thank you sooo much for that tid-bit. It actually makes a lot of logical performance sense, I was just wondering how one might do this approach. Late yesterday I verified Round Robin behaviour using a SEPARATE simple JNDI client (i.e not a Session/Entity/Message bean) which was of course outside the JBoss VM.
I've actually ALMOST got it to work by having the SLSB hosted on 2 nodes of a cluster, and having the MDB hosted on the 3rd, but having a "TransactionImpl not serializable" error, but think that is a mistake in the SLSB descriptor (no need for a transaction in this instance).
Your description of having separate JBoss VM's, one for the JMS, and one for the clustered beans is actually an incredibly simpler idea, can't believe I didn't try that.
Any idea when Clustering a JMS queue and MDB might be on the cards?
It is definitively on the todo list for 4.0. Furthermore, FYI load-balancing policies are "better" implemented (state shared accross the same proxies of a VM) in 3.2 so you may give it a try: 3.2.0RC1 should go out on Sunday.