Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
2 Major
-
Resolution: Fixed
-
Affects Version/s: 2.1.3
-
Fix Version/s: 2.1.4
-
Component/s: None
-
Labels:None
-
Terracotta Target:Quartz 2.1.4
-
Fixed In Revision:1988
Description
According to MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY documentation "the scheduler will simply try to fire [the trigger] as soon as it can". It works as expected with RAMJobStore.
However with JDBCJobStore nothing happens. Triggers with next scheduled time way in the past are simply ignored for good. Seems like the SQL query is purposely written to ignore triggers with MISFIRE_INSTRUCTION_IGNORE_MISFIRE_POLICY (-1):
SELECT COUNT(TRIGGER_NAME) FROM TRIGGERS WHERE SCHED_NAME = 'schedulerFactory' AND NOT (MISFIRE_INSTR = -1) --here's the problem AND NEXT_FIRE_TIME < 1333727366734 AND TRIGGER_STATE = 'WAITING'
If this is not a bug (?!?), why RAM job store works as described?
Activity
James House
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Issue Review Board [ drb ] | Anthony Dahanne [ adahanne ] |
| Fix Version/s | 2.1.4 [ 11088 ] | |
| Terracotta Target | Unknown [ [11113] ] | Quartz 2.1.4 [ [11342] ] |
Anthony Dahanne
made changes -
| Status | New [ 10000 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] | |
| Fixed In Revision | 1988 |
Gautam Jayaprakash
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Fiona O'Shea
made changes -
| Workflow | Public_workflow_20090225 [ 75819 ] | ExternalProjectWorkflow_201208 [ 87708 ] |
Fiona O'Shea
made changes -
| Workflow | ExternalProjectWorkflow_201208 [ 87708 ] | ExternalProjectWorkflow_201210 [ 96795 ] |
Fiona O'Shea
made changes -
| Workflow | ExternalProjectWorkflow_201210 [ 96795 ] | ExternalProjectWorkflow 201210 [ 100284 ] |
Yes, this looks like a bug indeed - but not with the specific query you point out. The query for handing misfires does purposely ignore those triggers with the misfire_instruction of ignore (-1). However I think the acquire trigger query (StdJDBCConstants.SELECT_NEXT_TRIGGER_TO_ACQUIRE) is probably ignoring triggers far in the past (further back than the misfire threshold), and therein lies the bug.