JMS Queue residing in a cluster

[malmit]

Is it correct to say that a JMS Queue residing in a cluster only exists on a single node in the cluster and fails over to another node upon failure? If this is the case, how does loadbalancing work if only one node handles all JMS Messages? The reason why I'm asking is because I've created a program which makes a JMX connection to all nodes in the proxy to get stats on the number of messages sent to it and only one of the nodes returns any results. When looking at the JMX console only that one server has the queue in the tree. Is this how JBoss JMS Clustering really supposed to work? I've read the JBoss documentation and Wiki but didn't seem to find it in the docs. If I missed it could someone please point it out to me. Thanks.

[genman]

A single node "holds" the messages and the other nodes consume them. If a single consumer is sufficiently fast, then the other nodes end up idle.

You may want a more round-robin configuration for your queue:

 <mbean code='org.jboss.mq.server.jmx.Queue' name='jboss.mq.destination:service=Queue,name=SMX'>
 <attribute name="ReceiversImpl">org.jboss.mq.server.ReceiversImplLinkedList</attribute>

[myparu]

Hi,

Where can I find this kind of info? I have been looking through the JBoss 4 book and searched a little on the site to configure Round-robin for queue consumers but didnt find any. May be I was searching with the wrong terms...

Murali

[genman]

Not sure... I would suggest bugging Adrian. :-)

It should be Round Robin by default, IMHO, but there's some reason he decided against it.

[adrian.brock]

"genman" wrote:

Not sure... I would suggest bugging Adrian. :-)

It should be Round Robin by default, IMHO, but there's some reason he decided against it.

I implemented the "round robin" because you guys kept bugging me about it.
It was an FAQ, and still is. :-(

I didn't make it the default because it just isn't good practice to change semantics
on people, especially when it can only be considered "experimental" compared
to the previous implementation as it says on the WIKI page.

In many respects, the sticky behaviour (that isn't actually guaranteed - its just an
undocumented feature of Sun's HashSet implementation)
is good as well if one instance can keep up with the load.

e.g. if the MDB is doing DB processing, that instance will already have relevant info
the cache.
e.g. you might want to avoid the contention of multiple servers competing for db locks,
although a singleton is better for the latter.

[adrian.brock]

"genman" wrote:

Not sure... I would suggest bugging Adrian. :-)

If you really want to "bug" me, buy a support contract.

Otherwise, you'll have post a question that is answerable,
hasn't been posted before and isn't covered in the free docs.

You also get access to our "knowledge base" which consolidates all the useful
information across all the JEMS products.
http://www.jboss.com/services/profsupport