HornetQ clustered queue and failing node: are messages lost?

Question

I'm facing a design issue in which I would like to have only one JMS producer sending messages to two consumers. There are only two servers, and the producer will start generating messages that will be load balanced (with round robin) to both consumers.

In the hypothetical case of one server failing, I do have a mechanism so a new producer will be activated in the remaining server. But what will happen to the messages that were being processed in the server that went down?

Will they be reassigned to the remaining server thus being processed by the remaining consumer? or they will be lost?

If the last case is true there will be another problem. The producer creates messages based on files in a NAS so when a server goes down, the newly activated producer will start creating messages based on the contents of the NAS and that may replicate messages (but that case is handled) the problem is that if the server that goes down is not the server with the active producer then when the server goes up again it will not have messages to consume and also no messages will replace the ones lost.

How can I achieve a design so that no messages are lost?

Note: When one server goes down, the journal and bindings are lost.

Answer 1

Once the message is transferred to a particular node it belongs to that node.

If a node goes down, you would have to activate that node with its journal and the message state would be recovered from disk. You could eventually have messages being redistributed if you don't have more consumers (that will depend on redistribution configuration of course).

Or the best approach would be to have a backup node for each node.

We have been advising the use of collocated topologies, where one VM has an active instance and a backup instance for the other Server... That way each alive server would also have a backup config. That's being improved on 2.4.0 as we speak as you need a lot of manual configuration at the moment.

So, in summary either:

• Restart the node
• configure backup nodes