[
https://issues.apache.org/jira/browse/CAMEL-17446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472219#comment-17472219
]
Karen Lease commented on CAMEL-17446:
-------------------------------------
>That idea is to simulate a "fireNow" by forcing a misfire
Yes, I see that, and I see the documentation of the parameter related to the
scheduler being started is consistent with the code.
But Quartz allows to set an explicit start and end time on a simple trigger,
and this isn't possible in Camel. That could be done with trigger.startTime and
trigger.endTime properties, where startTime would then override the
triggerStartDelay and be applied even when the scheduler is not yet started.
For now I submitted a PR for the log message and the documentation for
triggerParameters.
> Trigger start time for Quartz causes confusion with short trigger intervals
> ---------------------------------------------------------------------------
>
> Key: CAMEL-17446
> URL: https://issues.apache.org/jira/browse/CAMEL-17446
> Project: Camel
> Issue Type: Bug
> Components: camel-quartz
> Affects Versions: 3.13.0
> Reporter: Karen Lease
> Priority: Minor
>
> An issue reported on the users list shows that using
> trigger.repeatInterval=1200 causes the first 2 events to be fired sooner than
> expected after the scheduler is started.
> This is due to the delay between creating the Quartz Trigger and when the
> scheduler is started.
> Changing the log message to show the milliseconds in the trigger's next fire
> time would be helpful. In addition, it appears counter-intuitive that
> triggerStartDelay is ignored if positive, as shown in
> QuartzEndpoint.createTrigger() below:
> {code:java}
> if (getComponent().getScheduler().isStarted() || triggerStartDelay < 0) {
> triggerBuilder.startAt(new Date(System.currentTimeMillis() +
> triggerStartDelay));
> }{code}
> Is this intentional?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
