[jira] [Commented] (CAMEL-25659) camel-sjms - connection recovery can report success when the new connection fails before the consumers are created

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-25659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127337#comment-18127337 ] 

Claus Ibsen commented on CAMEL-25659:
-------------------------------------

Merged https://github.com/apache/camel/pull/27856 into main as 6319543d332f (4.24.0).

_Claude Code on behalf of davsclaus_

> 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
>            Priority: Minor
>             Fix For: 4.24.0
>
>
> 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)