I'm exploring jmsTemplate implementation and faced an issue. A JMSMessageId can be manually applied to a message, but a callback returns different MessageId.
Sample code:
log.debug("Sending request " + jmsMessageId);
final AtomicReference<Message> msg = new AtomicReference<>();
jmsTemplate.send(destinationQueue,
session -> {
Message message = session.createTextMessage(body);
message.setJMSMessageID(jmsMessageId);
msg.set(message);
return message;
});
log.debug("Request sent " + msg.get().getJMSMessageID());
The output is:
2019-05-14 15:36:41.308 DEBUG Sending request 2136b3c2-71c7-437a-892f-5e72d27a54f1
2019-05-14 15:36:41.487 DEBUG Request sent ID:414d51205445535420202020202020204be2be5c02e71527
I was expecting both IDs to be the same. Due to documentation from IBM:
The JMS_IBM_MQMD_MsgId property overrides the JMS default processing of the JMSMessageID property. When service integration converts messages to WebSphere MQ format, service integration checks whether the JMS_IBM_MQMD_MsgId property has been explicitly set. If so, service integration sets the MQMD MsgId field to this value (byte[]) , and replaces the unique value of the JMSMessageID that JMS allocates to the message.
So, the explicitly defined MsgId should not be overriden, only encoded? Is something missing in my config or this is a normal behaviour?
setJMSMessageId does nothing - from the javadocs.
This method is for use by JMS providers only to set this field when a message is sent. This message cannot be used by clients to configure the message ID. This method is public to allow a JMS provider to set this field when sending a message whose implementation is not its own.
(My emphasis).
In any case, the wording is opposite to what you are doing...
The JMS_IBM_MQMD_MsgId property overrides the JMS default processing of the JMSMessageID property. ...
i.e. you have to set the JMS_IBM_MQMD_MsgId property and it will override the generated JMSMessageID.