I don't think it is trivial. :-)
You cannot currently do this with JBossMQ. I don't know about other JMS
implementations. It doesn't sound like a typical solution - the design has lots of
points of failures (one for each network connection and database) unless
you plan on providing redundent copies (buddying).
Oh thanks for the reply Adrian. I was afraid you were going to yell at me! :)
If I can ask one more:
If the node (master node?) hosting the Topic fails, I learnt (from cocoonhive.org) we could have TopicSubscribers register an ExceptionListener and failover to a new node.
But since the subscribers themselves are on the node that failed, will they automatically move to another node too or do we do this manually?
Why would I yell at you? It is not a dumb question that has been asked
20 times in the last month. :-)
Actually, I misread your question. I though you were talking about splitting up the
physical topic, to store each subscription's messages on different machines.
The clients can be on as many nodes as you like.
You don't need clustering for this, you just have three clients making remote
If you do it with an MDB, then the exception listener/recovery is done for you.
What the clustering would give you is the ability to failover to a different machine
if one crashes. It would pickup the Topic messages from the database and continue
where the failed machine left off. But the full version isn't available until 3.2.4
It is doable in 3.2.3, but you have to put the pieces together yourself
(something we - Ivelin really - have done for you in 3.2.4).
As always, that was very helpful. Thanks Adrian.