This content has been marked as final. Show 4 replies
What is JBossMQ's behaviour under these circumstances?
If I send a message to a topic, and it ends up being delivered to n subscriptions on that topic, then the message expires, should the message be added to the expiry queue n times, one for each subscription, or only once?
JBossMQ creates an expired message for every subscription.
A more complex but related situation is for messages that have exceeded max delivery attempts.
If a message is sent to a topic with n subscriptions. Then depending on how many times the client calls recover() or rollback() for one or more of the subscriptions, then the message could have exceeded max delivery attempts for some of the subscriptions but not with others.
So the message needs to be added to the DLQ for some of the subscriptions, but not for others - how does this effect the subscriptions who have not exceeded max delivery attempts?
Can we end up with a situation where the same message (same message id) is in the queue (dlq or expiry queue) multiple times? Would we get primary key violations in the database?
How I did it was to basically create a new message, which is mostly a copy of the original message, with additional headers indicating the original message ID, queue or topic name, and time of expiry. Then, JBossMQ would remove the old message and store the new message as a single DB operation.
You don't really need to worry about ID conflicts therefore.
That makes sense.
I suggest we do the same for JBM
Ok, this is done, tested and committed in TRUNK.