Thank you for confirmation. I will do that and maybe propose a configurable option for the future release.
Pozdrawiam, Marcin Więckowski. pt., 26 wrz 2025, 10:20 użytkownik Claus Ibsen <[email protected]> napisał: > 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 >
