Old thread bump! I recently ran into a bug (i.e. I wrote bad code) where I was using message.reset() in a Guaranteed message publishing JCSMP app. Unlike with Direct messaging publishers, the broker sends ACKs and NACKs back to the publisher to indicate success for each Guaranteed message.
A common pattern is to use the published message object itself as the correlation key. This way, if the publisher receives a NACK, it simply grabs the key as the message, and then requeues it to try to resend. And here is my problem!
I was calling reset() on my single message object and reusing it each loop (like in my Direct messaging sample above). This was fine until I received a NACK and tried to get my message from the correlation key. But I had overwritten the message contents with following messages. Bad news!
So either:
a) create a new message object each loop for Guaranteed messages
b) don’t use the message object as the correlation key… keep all the payloads, topics, metadata in some data structure and use some other identifier as the key, and if you receive a NACK: rebuild the message from that source data.
Note that for Direct message publishing, reset() is totally fine as the broker will never ACK/NACK your message. It’s fire-and-forget. Oh, you may get a publish error due to publish ACL or something, but the correlation key will be null.
Hope this helps someone out there…!