apupier commented on code in PR #24819:
URL: https://github.com/apache/camel/pull/24819#discussion_r3601765901


##########
components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzAddRoutesAfterCamelContextStartedTest.java:
##########
@@ -36,12 +38,15 @@ public void testAddRoutes() throws Exception {
         context.addRoutes(new RouteBuilder() {
             @Override
             public void configure() {
-                
from("quartz://myGroup/myTimerName?trigger.repeatInterval=100&trigger.repeatCount=1").to("mock:result");
+                // use a generous interval (500ms) so that the Quartz scheduler
+                // can reliably fire both the initial and repeat triggers even
+                // on heavily-loaded CI machines (100ms was too tight)
+                
from("quartz://myGroup/myTimerName?trigger.repeatInterval=500&trigger.repeatCount=1").to("mock:result");

Review Comment:
   If the message is not sent when the repeat interval is low, I guess this is 
a bug and we should not change the test but fix the runtime. Isn't it?
   or we consider it normal to drop a message?



##########
components/camel-quartz/src/test/java/org/apache/camel/component/quartz/QuartzAddDynamicRouteTest.java:
##########
@@ -39,12 +41,15 @@ public void testAddDynamicRoute() throws Exception {
         context.addRoutes(new RouteBuilder() {
             @Override
             public void configure() {
-                
from("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1").routeId("myRoute")
+                // use a reasonable interval (200ms) so that the Quartz
+                // scheduler can reliably fire both triggers on loaded CI
+                // machines (2ms was far too tight for reliable scheduling)
+                
from("quartz://myGroup/myTimerName?trigger.repeatInterval=200&trigger.repeatCount=1").routeId("myRoute")
                         .to("direct:foo");
             }
         });
 
-        resultEndpoint.assertIsSatisfied();
+        MockEndpoint.assertIsSatisfied(context, 30, TimeUnit.SECONDS);

Review Comment:
   I think that the point of having a 2ms scheduling was too ensure that the 
repeatCount i well respected. By increasing to 200ms, we need to add some wait 
of at least 200ms to ensure that no other route is triggered and so that we 
have only 1 and then 2 messages.



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