Hi, I have stumbled upon the following problem. Our legacy platform uses JMS with Artemis server for request-reply scenarios. However, it uses custom headers instead of "JMSMessageID" and "JMSCorrelationId" for request-reply correlation. Request includes "msgId" header that is being copied to "corrId" header of the response message by the service provider. Service client wait for the reply with selector "corrId=<msgId>".
I have found two properties on JMS Component that looked promising: 1. correlationProperty = corrId 2. replyToDestinationSelectorName = corrId But: 1. Does not change the header's name used by selector, only uses the value of the specified header (keeps listening with selector "JMSCorrelationID=<corrId-from-request>") 2. Listens on correct header but with it's value from request: "corrId=<corrId-from-request-but-regenerated>" which would be ok but it also overwrites the value of "corrId" you set before sending the message (I set "msgId" to the same value as "corrId" because as I mentioned the providing service copies the value of "msgId" to "corrId") I found the following code responsible for this behaviour: 1. org.apache.camel.component.jms.reply.MessageSelectorCreator.get() where "JMSCorrelationId" is hardcoded. 2. org.apache.camel.component.jms.reply.QueueReplyManager.createDefaultListenerContainer() where replyToSelectorValue is always generated as new. I found solution that works by using to() with "InOnly" and pollEnrich() with custom selector, but it is not the best solution I think (pollEnrich creates new consumer each time it receives and I think sometime it happens too late and the response that go to the response topic (address in Artemis nomenclature) cannot be routed because customer queue is not created yet and therefore message is discarded) . Is there another solution that could work in my scenario? Using synchronous to() would be the best and cleanest. Kind regards, Marcin Wieckowski.
