chore(camel-test-infra-ibmmq): upgrade ibm.mq.container to 10.0.0.0-r3

[github-actions]

This PR updates the ibm.mq.container container image to version 10.0.0.0-r3.

Update Details

• Property: ibm.mq.container
• Image: icr.io/ibm-messaging/mq
• File: /home/runner/work/camel/camel/test-infra/camel-test-infra-ibmmq/src/main/resources/org/apache/camel/test/infra/ibmmq/services/container.properties
• Old version: 10.0.0.0-r2
• New version: 10.0.0.0-r3

Verification

Please verify:

• Container image version is compatible with existing tests
• No breaking changes in the updated version
• Tests pass with the new version

Run the following to rebuild the test infra:

mvn clean verify -pl camel-test-infra-ibmmq

Then test the impacted components.

---

This PR was automatically created by the Container Version Upgrade workflow.

[gnodet]

❌ Local IT results for 7d28291fc2353bc2955c22ffefa9e6fa9f29e133

Integration test failures detected — IBM MQ 10.0.0.0-r3 container takes longer to accept JMS connections, exceeding the 30-second timeout in IbmMQLocalContainerInfraService.

Test-infra module: camel-test-infra-ibmmq
Components tested: components/camel-jms

Test Results Summary

Metric	Count
Total tests	439
Passed	428
Failed (errors)	2
Skipped	9

Failures

Both failures are in @beforeAll — the container starts but the JMS service inside takes >30s to become ready:

1. JmsComponentIbmMQTest — ConditionTimeout: Condition 'IBM MQ accepting JMS connections' didn't complete within 30 seconds
2. JmsReplyToIbmMQTest — Same timeout error

Each test was retried 3 times with the same result — this is not a flake.

Root Cause

The Awaitility timeout in IbmMQLocalContainerInfraService.waitForJmsConnection() is set to 30 seconds. The new IBM MQ 10.0.0.0-r3 container takes longer to initialize its JMS listener.

Suggested Fix

Increase the Awaitility timeout from 30 seconds to 120 seconds in IbmMQLocalContainerInfraService.java:

Awaitility.await("IBM MQ accepting JMS connections")
        .atMost(120, TimeUnit.SECONDS)  // was 30 — IBM MQ 10.x needs more startup time
        .pollInterval(1, TimeUnit.SECONDS)

Local integration tests run by ForgeBot on behalf of @gnodet
Tests run without -Dci.env.name to include ITs disabled on GitHub Actions CI

[gnodet]

⚠️ Local IT results for 7d28291 — correction to previous report

Previous comment on this commit reported a timeout issue — that analysis was incorrect. The actual root cause is a Docker networking limitation in the ForgeBot test environment.

Diagnosis

Check	Result
IBM MQ 10.0.0.0-r3 container starts?	✅ Yes — Queue Manager QM1 operational, listener RUNNING on port 1414
MQ listener active inside container?	✅ Yes — DISPLAY LSSTATUS(*) shows STATUS(RUNNING)
Port reachable from host (localhost)?	❌ No — Connection refused
Port reachable via container IP?	❌ No — no route to 172.17.0.0/16
Other containers (e.g. nginx) reachable?	❌ No — same issue
docker0 bridge present?	❌ No — not visible from this namespace

Root Cause

ForgeBot runs inside a Docker container that shares the Docker daemon via socket mounting (/var/run/docker.sock). This means:

• ForgeBot can create and manage sibling containers via the Docker API
• ForgeBot cannot connect to sibling containers' published ports — they exist in a different network namespace with no route from the ForgeBot container

This affects all Testcontainers-based integration tests, not just IBM MQ. The timeout mentioned in the previous comment was a symptom, not the cause — increasing it from 30s to 120s still fails because the port is unreachable, not slow.

What we verified

• The IBM MQ 10.0.0.0-r3 container starts successfully and the queue manager initializes normally
• This is a major version upgrade (9.4.5.0 → 10.0.0.0) which may have behavioral changes, but container startup is not broken
• The 428/436 non-IBM-MQ JMS tests (using embedded ActiveMQ) all pass — only the 2 tests requiring the Docker container fail

Recommendation

This PR should be verified by:

1. CI — the automated CI pipeline (which has proper Docker networking)
2. A maintainer running ITs locally in a standard Docker environment (not DinD)
3. Specifically test: mvn verify -pl components/camel-jms -Dtest=JmsComponentIbmMQTest,JmsReplyToIbmMQTest

The container image itself appears healthy — the issue is purely environmental.

Local integration tests run by ForgeBot on behalf of @gnodet
Tests run without -Dci.env.name to include ITs disabled on GitHub Actions CI
Environment limitation: Docker socket mounting prevents network connectivity to sibling containers