I do confirm this is a bug, and opened https://issues.apache.org/jira/browse/CAMEL-23646, I'll provide a PR shortly.
To answer your questions: 1. no, it is just a bug :) 2. no, the recovery recreates both the connection and the session 3. There were no tests, in the PR I'll add some 4/5. no, it is not related with Oracle AQ at all, I managed to reproduce a similar scenario with Artemis https://github.com/apache/camel/pull/23639 - I'll backport it to camel-4.18.x stream as well, if you can test on the SNAPSHOT once merged would be great. Federico Il giorno ven 29 mag 2026 alle ore 11:04 KARTHIK PRABHU N < [email protected]> ha scritto: > > Hello Camel Team, > > We are observing an issue with Camel SJMS 1 when using Oracle AQ as the > JMS provider. We are using latest camel version 4.18.X. > > After a short interruption in connectivity to Oracle AQ, the Camel > consumer enters a recovery loop and does not return to stable message > consumption. The logs repeatedly show successful recovery, but recovery > starts again after approximately 5 seconds, indefinitely. > > Observed log pattern: > > We repeatedly see messages like: > > ```text > Recovering from JMS Connection exception (attempt: 125) > Created JMS Connection > Successfully recovered JMS Connection (attempt: 125) > > Recovering from JMS Connection exception (attempt: 126) > Created JMS Connection > Successfully recovered JMS Connection (attempt: 126) > ``` > > This continues indefinitely... > > In earlier logs, we can also see that the route successfully consumes and > processes a few messages before the recovery loop begins again, for example: > > ```text > onMessage.process START > Processing exchange ... > onMessage.process END > onMessage END > Recovering from JMS Connection exception (attempt: 2) > Created JMS Connection > Successfully recovered JMS Connection (attempt: 2) > ``` > > *Impact : * > Because recovery continues infinitely, normal message processing is > effectively blocked or stuck after the transient AQ interruption. > > *Current consumer configuration: * > > The endpoint is configured roughly as > > ```text > > ...queue:HS2K.QUEPOSTDATA?acknowledgementMode=CLIENT_ACKNOWLEDGE&asyncStartListener=true&concurrentConsumers=15 > ``` > > *Questions* > 1. Is this repeated recovery loop a known behavior in `sjms` after > transient JMS provider interruptions? > 2. Does `sjms` consider only connection recreation as “successful > recovery”, even if consumer/session startup later fails again? > 3. Are there existing tests covering a case where: > - connection is interrupted, > - recovery logs “Successfully recovered JMS Connection”, > - but the consumer immediately re-enters recovery again and never > stabilizes? > 4. Could this be related to `CLIENT_ACKNOWLEDGE`, listener startup, or > stale JMS/session objects after reconnect with Oracle AQ? > 5. Is there a recommended configuration for Oracle AQ to avoid this > behavior? > > I am attaching the relevant logs for reference. > > Please let us know if you need additional details such as Camel version, > AQ client version, or a minimal reproducer. > > Regards, > Karthik >
