You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2020/05/18 20:00:00 UTC
[jira] [Resolved] (CAMEL-13722) Quartz job paused, but not resumed
after zookeeper connection recovery leads to job misfire
[ https://issues.apache.org/jira/browse/CAMEL-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-13722.
---------------------------------
Resolution: Not A Bug
quartz also needs some kind of clustered databsase to keep its state about which job has fired and not. You cannot run quartz standalone and have zk-master component then do failover with quartz know about all of that.
Its more complex when using quartz. And what its options and scheduled next fire time and all of that is you have to look at hte quartz docs.
> Quartz job paused, but not resumed after zookeeper connection recovery leads to job misfire
> -------------------------------------------------------------------------------------------
>
> Key: CAMEL-13722
> URL: https://issues.apache.org/jira/browse/CAMEL-13722
> Project: Camel
> Issue Type: Bug
> Components: camel-quartz2
> Affects Versions: 2.22.0
> Reporter: Camel
> Priority: Minor
> Fix For: Future
>
>
> We have 2 instances of route coordinated by zookeeper with MasterRoutePolicy. If zookeeper is disconnected, the quartz job is paused and left in that state after connection recovery. Later on, if another node shuts down, current node with paused job starts the route, despite wrong time.
> How to reproduce:
> # Run 2 instances with MasterRoutePolicy for leader selection connected to zookeeper with route from("quartz2://foobar?cron=0+0+15+?+*+MON-FRI").log("start");
> # Simulate zookeeper disconnect (pull net cable etc.) on non-master -> Trigger is set to Paused. Log:
> [Curator-ConnectionStateManager-0] org.apache.camel.component.quartz2.QuartzEndpoint: Pausing trigger foobar
> # Reconnect to zookeeper
> # Master node successfully runs the scheduled job, wait 5 min
> # Shutdown master node -> the second node triggers the job even though it was already executed on master and cron time is in the past
> Expected behavior is to skip running missed job in step 5.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)