atiaomar1978-hub opened a new pull request, #25531: URL: https://github.com/apache/camel/pull/25531
## Summary _AI-generated on behalf of atiaomar1978-hub_ Fixes [CAMEL-24401](https://issues.apache.org/jira/browse/CAMEL-24401): camel-jms InOut producers using temporary reply queues could enter a permanent `Failed to resolve replyTo destination` loop after JMS connection faults. ### Root cause `TemporaryQueueReplyManager` used a one-shot `refreshWanted` flag that was cleared **before** a replacement temporary queue was published (Scenario B), and could remain armed with no consumer left to call the destination resolver (Scenario A). ### Fix - Replace `refreshWanted` with a monotonic **refresh generation** counter and only publish `replyTo` after a successful queue creation for the handled generation (prevents Scenarios B and C). - When a refresh is scheduled, **defer** listener-container recovery until after the endpoint recovery interval and skip while Spring is already recovering, forcing a resolver call for Scenario A without racing Spring recovery. - Add `DefaultJmsMessageListenerContainer.recoverReplyDestinationAfterRefresh()` as a guarded hook into Spring recovery. ### Tests - `TemporaryQueueReplyManagerRefreshTest` — failed create retry, latest generation publish, permanent failure, generation change during resolve - `JmsTemporaryReplyToRequestReplyIT` — consecutive InOut request-reply sanity check ### References - JIRA: https://issues.apache.org/jira/browse/CAMEL-24401 - Reproducer/analysis: https://github.com/vdobos-trask/Reproducer_Camel_Jms_Failed_ReplyTo_Destination_2026 ### Review notes Grok + Bugbot review feedback addressed: publish ordering, lock scope, deferred recovery, shutdown ordering. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
