apupier commented on code in PR #24698:
URL: https://github.com/apache/camel/pull/24698#discussion_r3593459780
##########
core/camel-core/src/test/java/org/apache/camel/component/direct/DirectProducerBlockingTest.java:
##########
@@ -98,8 +100,10 @@ public void run() {
}
});
- // This call will block until the route is resumed by the background
thread
- template.sendBody("direct:suspended?block=true&timeout=2000", "hello
world");
+ // This call will block until the route is resumed by the background
thread.
+ // Use a generous timeout so the background thread has enough headroom
to
+ // detect the TIMED_WAITING state and resume the route even under CI
load.
+ template.sendBody("direct:suspended?block=true&timeout=10000", "hello
world");
Review Comment:
the stacktrace sounds unrelated to the fact that it needs more time on these
timeouts, it is complaining about no consumer available, which means the route
with name `suspended` is not available
```
Caused by:
org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: direct://suspended?block=true&timeout=2000.
Exchange[]
```
https://develocity.apache.org/s/qawauqqv5yvp6/tests/goal/org.apache.camel:camel-core:surefire:test@default-test/details/org.apache.camel.component.direct.DirectProducerBlockingTest/testProducerBlocksResumeTest?top-execution=1
##########
components/camel-jms/src/test/java/org/apache/camel/component/jms/integration/JmsAddAndRemoveRouteManagementIT.java:
##########
Review Comment:
very likely that the flakiness is already fixed by
https://github.com/apache/camel/commit/148ac28d67cb45f711dcdabb16e5dd1d8839d930
given that there was no more flakiness reported since the 13th of July
https://develocity.apache.org/scans/tests?search.rootProjectNames=camel&search.tags=main&search.timeZoneId=Europe%2FParis&tests.container=org.apache.camel.component.jms.integration.JmsAddAndRemoveRouteManagementIT&tests.sortField=FLAKY&tests.test=testAddAndRemoveRoute&tests.unstableOnly=false
and the test is regulalry close to the 10seconds previous limits
##########
components/camel-disruptor/src/test/java/org/apache/camel/component/disruptor/DisruptorBlockWhenFullTest.java:
##########
@@ -57,7 +59,7 @@ void testDisruptorBlockingWhenFull() throws Exception {
assertEquals(QUEUE_SIZE, disruptor.getRemainingCapacity());
sendSoManyOverCapacity(DEFAULT_URI, QUEUE_SIZE, 20);
- MockEndpoint.assertIsSatisfied(context);
+ MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS);
Review Comment:
this test is not reported as flaky
https://develocity.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=camel&search.tags=main&search.timeZoneId=Europe%2FParis&tests.container=org.apache.camel.component.disruptor.DisruptorBlockWhenFullTest&tests.sortField=FLAKY&tests.test=testDisruptorBlockingWhenFull
##########
core/camel-core/src/test/java/org/apache/camel/component/seda/SedaBlockWhenFullTest.java:
##########
@@ -32,7 +32,7 @@
* Tests that a Seda producer supports the blockWhenFull option by blocking
when a message is sent while the queue is
* full.
*/
-@Timeout(20)
+@Timeout(60)
Review Comment:
60 seconds seems a bit long compared to usual execution time of tests (>7s
when in success)
It is right that since last attempt
https://github.com/apache/camel/commit/726fd8f02caf4168a60acda4549bb05f2010fc37
the global timeout is too low compared to internal timeout BUT the previosu
change doesn't make any sense. The flakyness reported is about too many
messages received so increasing the timeout can only allow to happen more often
and won't solve any solutions, so better to revert the previous change
##########
components/camel-disruptor/src/test/java/org/apache/camel/component/disruptor/DisruptorBlockWhenFullTest.java:
##########
@@ -57,7 +59,7 @@ void testDisruptorBlockingWhenFull() throws Exception {
assertEquals(QUEUE_SIZE, disruptor.getRemainingCapacity());
sendSoManyOverCapacity(DEFAULT_URI, QUEUE_SIZE, 20);
- MockEndpoint.assertIsSatisfied(context);
+ MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS);
Review Comment:
it is testDisruptorExceptionWhenFull which is reported as flaky
https://develocity.apache.org/scans/tests?search.rootProjectNames=camel&search.tags=main&search.timeZoneId=Europe%2FParis&tests.container=org.apache.camel.component.disruptor.DisruptorBlockWhenFullTest&tests.sortField=FLAKY&tests.test=testDisruptorExceptionWhenFull
##########
core/camel-core/src/test/java/org/apache/camel/component/scheduler/SchedulerNoPolledMessagesTest.java:
##########
@@ -33,11 +33,11 @@ public void testSchedulerNoPolledMessages() throws
Exception {
mock.expectedMinimumMessageCount(3);
// the first 2 fire quickly (100ms interval), but CI environments can
add
// significant jitter from GC pauses and CPU contention — use wide
windows
- mock.message(0).arrives().between(0, 2000).millis().beforeNext();
- mock.message(1).arrives().between(0, 2000).millis().beforeNext();
+ mock.message(0).arrives().between(0, 4000).millis().beforeNext();
+ mock.message(1).arrives().between(0, 4000).millis().beforeNext();
// the last message should be slower as the backoff idle has kicked in
// (backoffMultiplier=10 × delay=100ms = ~1000ms), but allow extra
margin for CI
- mock.message(2).arrives().between(200, 5000).millis().afterPrevious();
+ mock.message(2).arrives().between(200, 10000).millis().afterPrevious();
Review Comment:
given that it was already multiplied by 4 in a previous commit and the test
is still flaky, i have serious doubt that increasing again will change anything
https://github.com/apache/camel/commit/3009c0da4c7e9eeacd2c360c7a10dff0d53dd667
--
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]
