CAMEL-23437: Fix and re-enable flaky DisruptorReconfigureWithBlockingProducerTest

[gnodet]

CAMEL-23437

Summary

• Fix and re-enable DisruptorReconfigureWithBlockingProducerTest, which has been @Disabled since 2019

Root causes of flakiness

1. Fragile wall-clock timing assertion (watch.taken() < 2000): only 400ms margin over the theoretical 1600ms drain time, easily exceeded on slow CI machines
2. Race between producer and reconfiguration: the ConsumerEventHandler processes events asynchronously (calls processor.process() with a no-op callback and returns immediately), so the ring buffer drains in microseconds. The producer could send all 12 messages to the OLD disruptor before addRoutes() nullified the reference, causing mock:b to receive far fewer messages than expected
3. Non-volatile exception field across threads and tight 5-second timeouts

Changes

• Remove @Disabled annotation to re-enable the test
• Use explicit CountDownLatch synchronization: producer sends a first batch of 8 messages, signals, then waits for reconfiguration to complete before sending the second batch of 12 messages. This ensures the second batch deterministically goes through both consumers
• Use blockWhenFull=true on the producer URI (matching the test's name)
• Remove the fragile StopWatch timing assertion
• Make exception field volatile for proper cross-thread visibility
• Increase timeouts to generous values (10s/30s) and add explicit timeout to MockEndpoint.assertIsSatisfied
• Add proper error handling with finally for resultLatch

Verified stable with 30 consecutive passes locally and full disruptor test suite (102 tests).

[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-disruptor

All tested modules (8 modules)

• Camel :: Disruptor
• Camel :: JBang :: 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

---

⚙️ View full build and test results

[apupier]

How many times have you launched it locally?
Were you able to reproduce the flakiness locally without the change?

[gnodet]

Thanks for the review @apupier!

How many times have you launched it locally?

30 consecutive runs (10 + 20), all passed. The test completes consistently in under 1 second.

Were you able to reproduce the flakiness locally without the change?

Yes. With just removing @Disabled (keeping the original test logic), it failed 3 out of 5 runs — mock:b would receive only 6 messages instead of the expected minimum 10, timing out at 30 seconds. The root cause is that the ConsumerEventHandler processes events asynchronously (calls processor.process() with a no-op callback and returns immediately), so the ring buffer drains in microseconds. The producer could send all 12 messages to the old disruptor before addRoutes() completed the reconfiguration.

Claude Code on behalf of Guillaume Nodet