Hello,

I’m creating a standalone Java program that reads events from an UM channel (via JMS API) and processes them. An ack is sent to the server only after an event has been successfully processed so that the events are not lost if an error occurs.

I noticed that, in the case of an error and, hence, a message reprocessing, the EventID I see on the client is increased each time the processing starts. This is despite the fact that it is the very same message, just the second try to process it.

Is that OK?

If that’s OK: Is there any way to see that two messages are really the same message, just delivered a second time? EventID (JmsMessageId in the JMS lingo) gets increased. Is there a field that remains unchanged on redelivery?

Thank you.

The incremented EventID is perfectly normal, provided you are consuming from a queue (or a shared-queued durable), because as soon as the event is allocated to that consumer, it is taken off the queue. If you roll back, or disconnect without acknowledging, the event will get re-queued, which is technically a new physical copy of that message, hence the new EventID. As far as I remember, while one may find it confusing, this behaviour doesn’t violate the JMS spec. I guess what makes it confusing is that it is typical for queues only. In later versions when shared-queued durables are superseded by shared (indexed) durables, the event is not copied around and its event ID doesn’t change - another good reason to consider upgrading
I’m not aware of a built-in marker to indicate that messages are identical. If I’m not mistaken, Integration Server by default stamps events with a “uuid” property, whereby the same uuid would indicate a semantically identical event. If you have control over the application that generates the messages, you could take a similar approach.

Cheers,
Stefan