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

   ## Description
   
   `LumberjackMultiThreadIT.shouldListenToMessages` has been intermittently 
flaky in CI (observed on PR #25778, an unrelated PR that pulled 
`camel-lumberjack` into its build via a shared parent POM property change).
   
   ## Root cause
   
   - `LumberjackUtil.sendMessages()` waits up to **30 seconds** internally for 
ACKs via Awaitility (that bound was itself raised from Awaitility's 10s default 
in `5df5b4719ac1` to fix a prior CI flake).
   - `shouldListenToMessages()` only waited **5 seconds** on a `CountDownLatch` 
for all client threads to finish. Under load, a thread could legitimately take 
longer than 5s to receive its ACKs, so the latch wait could time out before the 
client finished — causing an intermittent failure.
   
   ## Fix
   
   - Widen the latch wait to 35s so it comfortably exceeds the internal 30s 
ACK-wait ceiling, with a comment explaining why (to discourage a future 
accidental shrink of either number).
   - Reduce client-side thread oversubscription: each client thread created its 
own `NioEventLoopGroup` with the default thread count (`2x available 
processors`); with up to 4 concurrent client threads this could oversubscribe 
CPU on constrained CI runners and slow down ACK delivery. Changed to 
`NioEventLoopGroup(1)` since each client only manages a single channel — Netty 
pins a channel to one event-loop thread for its lifetime, so extra threads in 
that group would sit idle.
   
   ## Testing
   
   Ran the full `camel-lumberjack` module test suite (`mvn -Pit verify`) 
locally — all 5 unit tests and the `LumberjackMultiThreadIT` integration test 
pass, with `shouldListenToMessages` completing in ~8.8s (well under the new 35s 
bound).
   
   ---
   _Claude Code on behalf of davsclaus_


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to