You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "allthingssecurity (via GitHub)" <gi...@apache.org> on 2026/10/15 00:05:25 UTC

[PR] CAMEL-25659: camel-sjms - recovery notices a connection failure that happens before the consumers are created [camel]

allthingssecurity opened a new pull request, #27856:
URL: https://github.com/apache/camel/pull/27856

   # Description
   
   [CAMEL-25659](https://issues.apache.org/jira/browse/CAMEL-25659)
   
   Follow-up of point 2 of the [review of #27799](https://github.com/apache/camel/pull/27799#pullrequestreview-5513241706) ([CAMEL-25612](https://issues.apache.org/jira/browse/CAMEL-25612), merged).
   
   Since CAMEL-25612, `SimpleMessageListenerContainer.recoverConnection` tries again when `onException` dropped the consumers while the attempt was creating them: `initConsumers` assigns the `sessions`/`consumers` sets before its loop, `onException` sets them to `null`, and the attempt checks `consumers == null` under `connectionLock` at the end.
   
   One window was left: an `onException` for the new connection that comes after `refreshConnection()` but before `initConsumers` assigns the sets. It sets fields to `null` that are already `null`, and it does not schedule another recovery because one is running. If the following create calls fail, the attempt fails and is repeated, as before. If the JMS provider still creates the sessions and consumers on the failed connection, the attempt reports success, and the container stays on a connection that delivers nothing until the next `onException`.
   
   Changes, all in `SimpleMessageListenerContainer`:
   
   - `onException` counts the failures (an `AtomicLong`), as its first statement.
   - The recovery attempt reads the count inside `refreshConnection`, after the old connection is closed and before the new one is created (so before the new connection has the container as its exception listener), and compares it under `connectionLock` at the end of the attempt, next to the existing `consumers == null` check. If it changed, the attempt sets the two sets to `null` (the consumers on the failed connection are closed with it by the next attempt) and returns `false`, so the recovery task runs again after `recoveryInterval`.
   - `refreshConnection()` keeps its signature (`protected final void`) and its behaviour; it calls a new private method that also returns the count.
   
   The count is read after the old connection is closed, not before the attempt, so that a provider that calls the exception listener when a connection is closed does not make every attempt fail. An `onException` of the old connection that is delivered late (after that point) costs one more attempt; nothing tells which connection an `onException` is for.
   
   No new retry loop and no new log: the extra attempts are those of the existing recovery task, after `recoveryInterval`, and the case logs at DEBUG like the `consumers == null` case. The count is never reset; only its change during an attempt is used.
   
   No upgrade guide entry: nothing a route can rely on changes.
   
   Tests:
   - New test in `SjmsConsumerRecoveryFailedAttemptTest`, `testRecoveryTriesAgainWhenConnectionFailsBeforeConsumersAreCreated`, with the tracking connection factory of the class (embedded Artemis, `concurrentConsumers=3`, `recoveryInterval=200`). After a simulated `onException`, the connection that the recovery creates calls its exception listener when it is started and does not start (it delivers nothing), while sessions and consumers can still be created on it. The test expects a third connection with 3 consumers, the failed one closed, and a message sent afterwards to be consumed. All waits are Awaitility with `atMost` or `MockEndpoint` assertions; no sleeps.
   - Without the change (main's `SimpleMessageListenerContainer`, same test) it fails: `connections: the recovery must try again, the connection failed before the consumers were created ==> expected: <3> but was: <2> within 20 seconds`. The other four tests of the class pass on main and with the change.
   - Removing the reset of the two sets in the new branch makes the new test fail (`consumers on the new connection ==> expected: <3> but was: <0>`): the next attempt would otherwise take the consumers of the failed connection for its own.
   - With the change: camel-sjms 139 tests, 0 failures, 5 skipped; camel-sjms2 (it uses the same container through `SjmsEndpoint`) 23 tests, 0 failures. Test reruns switched off.
   
   What was not run: no broker other than the embedded Artemis; the failure of the new connection is simulated by the connection factory of the test.
   
   Notes:
   - `ExclusiveQueueMessageListenerContainer` and `TemporaryQueueMessageListenerContainer` (the reply listeners of the InOut producer) do not override `onException` or `recoverConnection`, so they get the change too.
   - The open pull request #27173 (CAMEL-16039) changes `onException` in the same file (it moves the reset of the two sets into a protected `invalidateConsumers()`). The two merge without a conflict today, and its `BatchMessageListenerContainer.onException` calls `super.onException`, so its failures are counted. Two points for whichever lands second: its worker-exit path calls `invalidateConsumers()` and `scheduleConnectionRecovery()` directly, not `onException`, so it is not counted (it is not a connection failure); and the reset that this change adds in `recoverConnection` would then better call `invalidateConsumers()` too.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it).
     [CAMEL-25659](https://issues.apache.org/jira/browse/CAMEL-25659), requested in the [review of #27799](https://github.com/apache/camel/pull/27799#pullrequestreview-5513241706).
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful subject line and body.
   - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes.
     (I built and tested camel-sjms and camel-sjms2, including the formatter and import-sort plugins. I did not run the full root build.)
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used.
     This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] CAMEL-25659: camel-sjms - recovery notices a connection failure that happens before the consumers are created [camel]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27856:
URL: https://github.com/apache/camel/pull/27856#issuecomment-6184480673

   :star2: Thank you for your contribution to the Apache Camel project! :star2:
     :robot: CI automation will test this PR automatically.
   
     :camel: Apache Camel Committers, please review the following items:
   
     * First-time contributors **require MANUAL approval** for the GitHub Actions to run
     * You can use the command `/component-test (camel-)component-name1 (camel-)component-name2..` to request a test from the test bot although they are normally detected and executed by CI.
     * You can label PRs using `skip-tests` and `test-dependents` to fine-tune the checks executed by this PR.
     * Build and test logs are available in the summary page. **Only** [Apache Camel committers](https://camel.apache.org/community/team/#committers) have access to the summary.
     
     :warning: Be careful when sharing logs. Review their contents before sharing them publicly.


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] CAMEL-25659: camel-sjms - recovery notices a connection failure that happens before the consumers are created [camel]

Posted by "davsclaus (via GitHub)" <gi...@apache.org>.
davsclaus merged PR #27856:
URL: https://github.com/apache/camel/pull/27856


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] CAMEL-25659: camel-sjms - recovery notices a connection failure that happens before the consumers are created [camel]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27856:
URL: https://github.com/apache/camel/pull/27856#issuecomment-6184860075

   <!-- ci-tested-modules -->
   :test_tube: **CI tested the following changed modules:**
   
   - `components/camel-sjms`
   
   ---
   
   <details><summary>:microscope: Scalpel shadow comparison — Scalpel: 10 of 703 tested, 27 compile-only — current: 10 all tested</summary>
   
   [Maveniverse Scalpel](https://github.com/maveniverse/scalpel) detected **10 affected modules** (current approach: 10).
   
   **Skip-tests mode would test 10 modules** (1 direct + 9 downstream), **skip tests for 27** (generated code, meta-modules)
   
   <details><summary>Modules Scalpel would test (10)</summary>
   
   - `camel-jbang-mcp` ← downstream of org.apache.camel:camel-catalog
   - `camel-jbang-plugin-mcp` ← downstream of org.apache.camel:camel-jbang-core
   - `camel-jbang-plugin-tui` ← downstream of org.apache.camel:camel-catalog
   - `camel-jbang-plugin-validate` ← downstream of org.apache.camel:camel-yaml-dsl-validator
   - `camel-launcher-container` ← downstream of org.apache.camel:camel-launcher
   - `camel-mllp` ← downstream of org.apache.camel:camel-sjms
   - `camel-sjms` ← components/camel-sjms/src/main/java/org/apache/camel/component/sjms/consumer/SimpleMessageListenerContainer.java, components/camel-sjms/src/test/java/org/apache/camel/component/sjms/consumer/SjmsConsumerRecoveryFailedAttemptTest.java
   - `camel-sjms2` ← downstream of org.apache.camel:camel-sjms
   - `camel-yaml-dsl-validator` ← downstream of org.apache.camel:camel-catalog
   - `camel-yaml-dsl-validator-maven-plugin` ← downstream of org.apache.camel:camel-yaml-dsl-validator
   
   </details>
   
   <details><summary>Modules with tests skipped (27)</summary>
   
   - `apache-camel`
   - `camel-allcomponents`
   - `camel-catalog`
   - `camel-catalog-console`
   - `camel-catalog-maven`
   - `camel-catalog-suggest`
   - `camel-componentdsl`
   - `camel-endpointdsl`
   - `camel-endpointdsl-support`
   - `camel-itest`
   - `camel-jbang-core`
   - `camel-jbang-it`
   - `camel-jbang-main`
   - `camel-jbang-plugin-edit`
   - `camel-jbang-plugin-generate`
   - `camel-jbang-plugin-kubernetes`
   - `camel-jbang-plugin-test`
   - `camel-kamelet-main`
   - `camel-launcher`
   - `camel-report-maven-plugin`
   - `camel-route-parser`
   - `camel-yaml-dsl`
   - `camel-yaml-dsl-deserializers`
   - `camel-yaml-dsl-maven-plugin`
   - `coverage`
   - `docs`
   - `dummy-component`
   
   </details>
   
   > :information_source: Shadow mode — Scalpel observes but does not affect test execution. [Learn more](https://github.com/maveniverse/scalpel)
   
   </details>
   
   <details><summary>All tested modules (37 modules, 7m 5s total)</summary>
   
   **Total reactor time:** 7m 5s
   
   | Module | Duration | Status |
   | --- | --- | --- |
   | Camel :: MLLP | 58.7s | SUCCESS |
   | Camel :: Simple JMS | 57.8s | SUCCESS |
   | Camel :: Launcher | 49.4s | SUCCESS |
   | Camel :: JBang :: MCP | 40.5s | SUCCESS |
   | Camel :: JBang :: Plugin :: Validate | 33.8s | SUCCESS |
   | Camel :: Component DSL | 22.3s | SUCCESS |
   | Camel :: Catalog :: Camel Catalog | 21.4s | SUCCESS |
   | Camel :: YAML DSL :: Validator | 18.0s | SUCCESS |
   | Camel :: YAML DSL | 17.8s | SUCCESS |
   | Camel :: Docs | 14.2s | SUCCESS |
   | Camel :: Kamelet Main | 12.7s | SUCCESS |
   | Camel :: JBang :: Plugin :: Kubernetes | 11.5s | SUCCESS |
   | Camel :: JBang :: Plugin :: Testing | 8.8s | SUCCESS |
   | Camel :: Simple JMS2 | 8.6s | SUCCESS |
   | Camel :: YAML DSL :: Deserializers | 7.3s | SUCCESS |
   | Camel :: Catalog :: Camel Route Parser | 7.3s | SUCCESS |
   | Camel :: Catalog :: Camel Report Maven Plugin | 6.4s | SUCCESS |
   | Camel :: All Components Sync point | 5.5s | SUCCESS |
   | Camel :: YAML DSL :: Validator Maven Plugin | 4.1s | SUCCESS |
   | Camel :: YAML DSL :: Maven Plugins | 3.0s | SUCCESS |
   | Camel :: Catalog :: Maven | 2.8s | SUCCESS |
   | Camel :: Catalog :: Suggest (deprecated) | 2.1s | SUCCESS |
   | Camel :: Assembly | 1.6s | SUCCESS |
   | Camel :: JBang :: Plugin :: Edit | 1.4s | SUCCESS |
   | Camel :: Coverage | 1.1s | SUCCESS |
   | Camel :: Catalog :: Dummy Component | 1.1s | SUCCESS |
   | Camel :: JBang :: Plugin :: Generate | 1.1s | SUCCESS |
   | Camel :: JBang :: Main | 1.0s | SUCCESS |
   | Camel :: Catalog :: Console | 0.9s | SUCCESS |
   | Camel :: JBang :: Integration tests | 0.9s | SUCCESS |
   | Camel :: Endpoint DSL :: Support | 0.8s | SUCCESS |
   | Camel :: Launcher :: Container | 0.7s | SUCCESS |
   | Camel :: JBang :: Plugin :: MCP | 0.6s | SUCCESS |
   | Camel :: Endpoint DSL | n/a |  |
   | Camel :: Integration Tests | n/a |  |
   | Camel :: JBang :: Core | n/a |  |
   | Camel :: JBang :: Plugin :: TUI | n/a |  |
   
   **Top 20 slowest modules:**
   - `Camel :: MLLP` (58.7s)
   - `Camel :: Simple JMS` (57.8s)
   - `Camel :: Launcher` (49.4s)
   - `Camel :: JBang :: MCP` (40.5s)
   - `Camel :: JBang :: Plugin :: Validate` (33.8s)
   - `Camel :: Component DSL` (22.3s)
   - `Camel :: Catalog :: Camel Catalog` (21.4s)
   - `Camel :: YAML DSL :: Validator` (18.0s)
   - `Camel :: YAML DSL` (17.8s)
   - `Camel :: Docs` (14.2s)
   - `Camel :: Kamelet Main` (12.7s)
   - `Camel :: JBang :: Plugin :: Kubernetes` (11.5s)
   - `Camel :: JBang :: Plugin :: Testing` (8.8s)
   - `Camel :: Simple JMS2` (8.6s)
   - `Camel :: YAML DSL :: Deserializers` (7.3s)
   - `Camel :: Catalog :: Camel Route Parser` (7.3s)
   - `Camel :: Catalog :: Camel Report Maven Plugin` (6.4s)
   - `Camel :: All Components Sync point` (5.5s)
   - `Camel :: YAML DSL :: Validator Maven Plugin` (4.1s)
   - `Camel :: YAML DSL :: Maven Plugins` (3.0s)
   
   </details>
   
   ---
   :gear: [View full build and test results](https://github.com/apache/camel/actions/runs/38657984151)


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org