-
15. Re: Exception when starten 2nd node
How to deploy a clustered queue to jboss as? Which attributes must be set in a clustered environment,which in a non clustered environment?
In which way does a message driven bean implement load balancing? How can i perform smoke tests with my cluster?
Following example: a clustered mdb on two nodes, putting 10000 messages into it and let the mdg work. The mdb logs out the message?
What happens? Only one node is working on the queue, the second does nothing. Adding a sleep(100) to the onMessage() does a wonder, both nodes are processing the mdb.
I explained me this behavior in follwoing way:
- mdb always use local jms connections
- message sucker distributes messages to other nodes (there must be an association between mdb throughput and distribution)
Now this sounds easy, but there a so many find grained parameters:
- deploy queue clustered or non clustered
- deploy queue as ha singleton or not
- a combination of both
So what I really need is a guide how to configure queues, mdb's and jboss messaging in a clustered/non clustered environment. How to smoke test?
How failsafe is the configuration, which problem may occur in worse case? -
16. Re: Exception when starten 2nd node
I think all this information is in the user guide, or has been answered several times already in different threads on this forum (have a search), but here goes again:
"mbreuer" wrote:
How to deploy a clustered queue to jboss as? Which attributes must be set in a clustered environment,which in a non clustered environment?
The "clustered" attribute on the queue/topic determines whether the queue or topic is clustered. Clustered queues/topics must be deployed on all nodes of the cluster. The easiest way to do this is to use the farm service.
Following example: a clustered mdb on two nodes, putting 10000 messages into it and let the mdg work. The mdb logs out the message?
What happens? Only one node is working on the queue, the second does nothing. Adding a sleep(100) to the onMessage() does a wonder, both nodes are processing the mdb.
I explained me this behavior in follwoing way:
- mdb always use local jms connections
- message sucker distributes messages to other nodes (there must be an association between mdb throughput and distribution)
Yes, you're almost right. The queue will always favour local consumers if they are able to cope with the load, if they are busy with work, then it will get distributed to other nodes. This is an optimal use of processing resources - there's no point in sending to other nodes if the local node has spare cycles. This behaviour can be turned off (see user guide).
Now this sounds easy, but there a so many find grained parameters:
- deploy queue clustered or non clustered
Yes, it's easy - if you want it clustered set clustered to true, if not set to false
- deploy queue as ha singleton or not
JBM does not normally use HASingleton - but if you want it to work like JBoss MQ you can, there's a FAQ on this
The distribution contains a set of examples including clustering and failover example which demonstrate how this is configured and how it works.