CAMEL-24600: Fix flaky test JmsConcurrentConsumerInOnlyTest.testConcurrentConsumers

[gnodet]

Problem

JmsConcurrentConsumerInOnlyTest.testConcurrentConsumers is flaky — it has failed 13 times in 90 days, always on s390x.

The test sends 2000 messages to a JMS queue through concurrent consumers (2-5) with random 0-10ms delays per message, then calls MockEndpoint.assertIsSatisfied(context) with no explicit timeout. This falls back to the default 10-second waitForCompleteLatch, which is insufficient on slow architectures (s390x, aarch64) or under CI load.

Fix

Replace MockEndpoint.assertIsSatisfied(context) with MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS) to use an explicit 30-second timeout.

This is consistent with JmsDefaultTaskExecutorTypeTest in the same module, which already uses MockEndpoint.assertIsSatisfied(context, 40, TimeUnit.SECONDS).

JIRA: https://issues.apache.org/jira/browse/CAMEL-24600

AI agent (Hermes on behalf of gnodet)

[apupier]

several unrelated changes

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 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 have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-jms

---

🔬 Scalpel shadow comparison — Scalpel: 1 tested, 0 compile-only — current: 12 all tested

Maveniverse Scalpel detected 1 affected modules (current approach: 12).

Modules only in current approach (11)

• camel-activemq
• camel-activemq6
• camel-amqp
• camel-jbang-mcp
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-launcher-container
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin

Skip-tests mode would test 1 modules (1 direct + 0 downstream), skip tests for 0 (generated code, meta-modules)

Modules Scalpel would test (1)

• camel-jms

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• components/camel-jms: 3 test(s) disabled on GitHub Actions

All tested modules (12 modules, 3m 2s total)

Total reactor time: 3m 2s

Module	Duration	Status
Camel :: ActiveMQ 5.x	44.6s	SUCCESS
Camel :: JBang :: MCP	38.2s	SUCCESS
Camel :: JBang :: Plugin :: TUI	36.3s	SUCCESS
Camel :: ActiveMQ 6.x	29.7s	SUCCESS
Camel :: AMQP	17.1s	SUCCESS
Camel :: YAML DSL :: Validator	4.9s	SUCCESS
Camel :: YAML DSL :: Validator Maven Plugin	4.1s	SUCCESS
Camel :: JBang :: Plugin :: MCP	2.4s	SUCCESS
Camel :: Launcher :: Container	2.1s	SUCCESS
Camel :: JBang :: Plugin :: Route Parser	1.7s	SUCCESS
Camel :: JBang :: Plugin :: Validate	0.9s	SUCCESS
Camel :: JMS	n/a

Top 20 slowest modules:

• Camel :: ActiveMQ 5.x (44.6s)
• Camel :: JBang :: MCP (38.2s)
• Camel :: JBang :: Plugin :: TUI (36.3s)
• Camel :: ActiveMQ 6.x (29.7s)
• Camel :: AMQP (17.1s)
• Camel :: YAML DSL :: Validator (4.9s)
• Camel :: YAML DSL :: Validator Maven Plugin (4.1s)
• Camel :: JBang :: Plugin :: MCP (2.4s)
• Camel :: Launcher :: Container (2.1s)
• Camel :: JBang :: Plugin :: Route Parser (1.7s)
• Camel :: JBang :: Plugin :: Validate (0.9s)

---

⚙️ View full build and test results

[gnodet]

Re-reviewing after the latest commit (9d522fb). The previous CHANGES_REQUESTED review ("several unrelated changes") was on an earlier iteration. The current PR modifies exactly one file with one logical change.

The fix is correct and ready to merge:

• Replaces the implicit 10-second waitForCompleteLatch default with an explicit 30-second timeout — directly addressing the root cause of the flakiness on s390x/aarch64.
• 30s is proportionate: 2000 messages × avg 5ms delay ÷ 2 concurrent threads ≈ 5s nominal; 30s leaves adequate headroom for slow CI architectures without bloating the test suite. The analogous JmsDefaultTaskExecutorTypeTest uses 40s for a heavier workload — these are consistent.
• Static analysis (ast-grep, semgrep): no findings.
• No unrelated changes remain — the CHANGES_REQUESTED concern has been fully addressed.

---

This review was generated by an AI agent, Hermès, on behalf of @gnodet.

[apupier]

on this one I feel there is something odd that might occur in the product code in some cases which could explain that it is 100x slower sometimes.

note that it doesn't fix the error on retries.

but we can try just to lower teh number of times it is flaky