shashank created CAMEL-25659:
--------------------------------

             Summary: camel-sjms - connection recovery can report success when 
the new connection fails before the consumers are created
                 Key: CAMEL-25659
                 URL: https://issues.apache.org/jira/browse/CAMEL-25659
             Project: Camel
          Issue Type: Bug
          Components: camel-sjms
            Reporter: shashank
            Assignee: shashank


Follow-up requested in the review of 
[#27799|https://github.com/apache/camel/pull/27799] (CAMEL-25612, merged).

Since CAMEL-25612, {{SimpleMessageListenerContainer.recoverConnection}} notices 
that an {{onException}} cut a recovery attempt short: {{initConsumers}} assigns 
the {{sessions}}/{{consumers}} sets before its loop, {{onException}} nulls 
them, and {{recoverConnection}} checks them under {{connectionLock}} at the end.

One window remains: an {{onException}} for the new connection that arrives 
after {{refreshConnection()}} but before {{initConsumers}} assigns the sets. It 
nulls fields that are still null, so the signal is lost. This is harmless when 
the following create calls fail, which is the usual case after a connection 
failure. If the JMS provider still creates the sessions and consumers on the 
failed connection, the attempt reports success and the container has no working 
consumer until the next failure.

h3. Proposed fix

A failure counter, independent of the create calls: {{onException}} increments 
it, {{recoverConnection}} reads it after {{refreshConnection()}} and compares 
it again under {{connectionLock}} at the end; if it changed, the attempt is not 
done and the recovery task runs again.

h3. Test

A test with a connection factory whose connection reports a failure through its 
{{ExceptionListener}} before the consumers are created while the create calls 
still succeed: without the change the recovery reports success with no working 
consumer; with the change a further attempt runs and messages are consumed 
again.

_Filed with Claude Code on behalf of allthingssecurity._




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to