Hi You can try to patch the code and change that selector to use your custom header name, and see how that goes. Then maybe we can make this configurable in a future Camel release.
On Fri, Sep 19, 2025 at 12:11 PM Marcin W. <[email protected]> wrote: > 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. > -- Claus Ibsen
