-
1. Re: good idea to use msg id for dup id?
I guess what I'm looking for is a way to reproduce the dup_id after a crash/reboot without having to write to a journal or similar persistence storage. What I worry is that a temporary queue would reset the starting message id and I could have ignored messages on the receiving queue.
I looked at the cluster bridge code, and it looks like it uses nodeName + messageID. But, it looks like a journaled/persistence enabled HornetQ impl does generate new message ids from a restart, but a non-persistence enabled HornetQ impl resets the first message id.
Would msg.getTimestamp() + msg.getMessageID() be good? timestamp should be the same on a message redelivery after a restart?
-
2. Re: good idea to use msg id for dup id?
If I understand what you want to do correctly:
You have server A with some persistent messages in it
You consume messages from serverA and forward them to server B
In event of crash of server A you may end up forwarding same messages again to B, so you want server B to reject duplicates?
If there is only one server, server A that forwards to server B, then you can safely just use the message id for the dup_id since that is guaranteed to be unique *per server*.
If there is more than one server forwarding to server B that may not work since different servers may produce the same set of server ids. This is why we add the node id on the core bridge to make it unique.
getTimestamp may not help you much since there may be more than one message with same timestamp and message id on different servers. Unlikely but possible depending on volume.
One other possibility is to generate a GUID at the client side before sending to the initial server and set it as the dup_id. As the message is received at the initial server this will get persisted and if that server crashes on recovery the message will be recovered with the same dup_id that you set, this can then be safely forwarded to any server.