Skip to content

v3.22.7

Choose a tag to compare

View all tags
@lahma lahma released this 19 Oct 12:19
v3.22.7
31c81b1

Fixes for the 3.x line, ported from 4.6. There is no public API change and no schema change.

Fixed

  • A trigger re-applied at startup keeps its previous fire time. Creating a scheduler re-applies the triggers the configuration registers through RescheduleJob, which replaced the stored trigger with one that had none, so PreviousFireTimeUtc was lost on every restart. It is now carried over when the replacement has none. (#4127, from #4122)
  • A recovered trigger keeps its job's execution group. A firing replayed after a node failure, a shutdown hand-back or startup recovery was stored ungrouped and ran beside a live firing of the same group, whatever the group's limit. (#4085)
  • A manual firing carries the execution group its job's triggers share. TriggerJob and the dashboard's Trigger now carried none, so they ignored the group's limit. (#4110)
  • Names in IConfiguration keep their case. A hierarchical section camel-cased every path segment on its way to the flat quartz.* keys, names the user chose included, and StdSchedulerFactory looks names up ordinally: Quartz:DataSource:MyDS beside Quartz:JobStore:DataSource = MyDS failed with no data source found. Data source, listener, execution-limit and context names now keep their case, and a plugin's name stays camel-cased, so the XML plugin's stored file-scan job keeps its key. (#4108)
  • The dashboard's cron preview uses the trigger's time zone and calendar, and previews the expression being edited. (#4118)

Warnings

  • A clustered scheduler warns when every node would share the instance id NON_CLUSTERED, which makes each node read the other's fired triggers as its own. Set quartz.scheduler.instanceId to AUTO, or a distinct id per node. 4.6 generates the id instead; 3.x keeps the default, because changing it would re-key an existing deployment's rows. (#4106)
  • A generated job or trigger identity in a persistent store logs a warning: a generated key is new on every start, so a persistent store keeps another copy each time, and every copy of a trigger fires. Give it a stable key with WithIdentity. (#4114)

What's Changed

Other changes

  • A recovered trigger keeps its job's execution group (3.x) by @lahma in #4085
  • A clustered scheduler warns when every node would share the instance id NON_CLUSTERED (3.x) by @lahma in #4106
  • A manual firing carries the execution group its job's triggers share (3.x) by @lahma in #4110
  • Names in IConfiguration keep their case (3.x) by @lahma in #4108
  • A generated job or trigger identity in a persistent store logs a warning (3.x) by @lahma in #4114
  • The dashboard's cron preview uses the trigger's zone and calendar, and previews the expression being edited (3.x) by @lahma in #4118
  • A trigger re-applied at startup keeps its previous fire time (3.x) by @lahma in #4127

Full Changelog: v3.22.6...v3.22.7

Contributors

lahma
Assets 3
Loading
0 Join discussion