This is an automated email from the ASF dual-hosted git repository.
apupier pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 48d063cfde0a CAMEL-26379: camel-quartz - attempt to stabilize
QuartzCronRouteWithStartDateEndDateTest
48d063cfde0a is described below
commit 48d063cfde0a800a08afa784b63e9eadd87f0266
Author: Aurélien Pupier <[email protected]>
AuthorDate: Fri Nov 6 14:23:51 2026 +0100
CAMEL-26379: camel-quartz - attempt to stabilize
QuartzCronRouteWithStartDateEndDateTest
This is an attempt to stabilize a flaky test; it has not been possible
to reproduce the failure locally, so the effect is not proven.
The test is reported flaky on CI (about 56% of the builds) with
"mock://result Received message count 0, expected at least 2", and it
then takes about 32 seconds because of the 30 seconds mock timeout.
Hypothesis: the trigger startAt/endAt dates were computed when the
RouteBuilder was configured, i.e. while the CamelContext was starting.
On a loaded CI machine a slow startup (Quartz scheduler / JMX
initialization) can consume part or all of the 4 seconds firing window.
In the worst case QuartzEndpoint.hasTriggerExpired() considers that the
trigger will never fire and does not schedule it, so no message is ever
received.
Change: add the route from the test method, once the CamelContext is
started, so that the start and end dates are computed just before the
trigger is created and are not affected by the context startup time.
The start offset is reduced from 5s to 3s as it no longer needs to
cover the startup; the firing window stays at 4 seconds.
Local verification, under heavy CPU load (load average about 45 on 22
cores): the test passed 20/20 with the change, but also 20/20 without it
(and 8/8 when running the whole camel-quartz module without it), so the
failure could not be reproduced and the benefit remains to be confirmed
on CI.
Co-authored-by: IBM Bob 2.2.1
Signed-off-by: Aurélien Pupier <[email protected]>
---
.../QuartzCronRouteWithStartDateEndDateTest.java | 24 ++++++++++------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git
a/components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzCronRouteWithStartDateEndDateTest.java
b/components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzCronRouteWithStartDateEndDateTest.java
index d9d155745951..b634cd7d795d 100644
---
a/components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzCronRouteWithStartDateEndDateTest.java
+++
b/components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzCronRouteWithStartDateEndDateTest.java
@@ -39,30 +39,28 @@ public class QuartzCronRouteWithStartDateEndDateTest
extends BaseQuartzTest {
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedMinimumMessageCount(2);
- // use timed assertion — the trigger starts 5s in the future and
- // fires for 4 seconds, so messages arrive between ~5s and ~9s
- MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS);
- assertThat(mock.getReceivedExchanges().size() <= 5,
CoreMatchers.is(true));
- }
-
- @Override
- protected RouteBuilder createRouteBuilder() {
- return new RouteBuilder() {
+ // add the route once the CamelContext is started, so that the start
and end dates are computed just before
+ // the trigger is created. When computed at CamelContext startup, a
slow startup on a loaded CI could make the
+ // whole firing window elapse, and the trigger would then never be
scheduled
+ context.addRoutes(new RouteBuilder() {
public void configure() {
SimpleDateFormat dateFormat = new
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssz");
Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(TimeZone.getTimeZone("UTC"));
- calendar.add(Calendar.SECOND, 5);
+ calendar.add(Calendar.SECOND, 3);
Date startDate = calendar.getTime();
calendar.add(Calendar.SECOND, 4);
Date endDate = calendar.getTime();
// triggers every 1th second at precise 00,01,02,03..59 with
startAt and endAt 4 seconds apart.
- // give plenty of headroom (5s) for route setup before the
trigger window opens,
- // so that Quartz scheduler initialization doesn't eat into
the firing window on loaded CI
fromF("quartz://myGroup/myTimerName?cron=0/1 * * * *
?&trigger.startAt=%s&trigger.endAt=%s",
dateFormat.format(startDate),
dateFormat.format(endDate)).to("mock:result");
}
- };
+ });
+
+ // use timed assertion — the trigger starts 3s in the future and
+ // fires for 4 seconds, so messages arrive between ~3s and ~7s
+ MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS);
+ assertThat(mock.getReceivedExchanges().size() <= 5,
CoreMatchers.is(true));
}
}
