Persistent cluster-friendly scheduler for Java
alwaysPersistTimestampInUTC()
for MySQL and MariaDB users (#471), closes #471. This PR changed the default behavior, which was later reverted in #481. See PR description for details.TIMESTAMP(6) WITH TIME ZONE
.We'd like to thank the following people for their contributions:
Disclaimer: This is a major release in the sense that the changes in this release affects a larger part of the codebase. In particular, polling logic and per-database customizations (like LIMIT
). There is good test-coverage for all of these changes, but I would still advice to let it sit in a test-environment for a while before promoting to production, to verify it is working as expected and does not produce any noise in the logs. Se PR #371 for more details.
We'd like to thank the following people for their contributions:
SchedulerClient.getScheduledExecution()
will now also return executions with an unresolved taskSchedulerClient.getScheduledExecutions()
will now also by default return executions with unresolved tasksScheduledExecutionsFilter.all()
will now indicate that also executions with unresolved tasks should be returnedWe'd like to thank the following people for their contributions:
We'd like to thank the following people for their contributions:
We'd like to thank the following people for their contributions:
We'd like to thank the following people for their contributions:
We'd like to thank the following people for their contributions:
Additionally, a big thanks to our two new sponsors, matt-snider and robinheghan 🎉.
JdbcCustomizer
in spring boot via DbSchedulerCustomizer
. The same PR also fixes missing serialVersionUID
for Serializable classes. This will be a breaking change for everyone already using dynamic recurring tasks, i.e PersistentCronSchedule
and friends. See notes below.Breaking changes
Unfortunately a couple of Serializable
classes missing serialVersionUID
was added in previous releases (releated to dynamic recurring tasks). This was a mistake, as that will break Java serialization for all changes to the classes, even if they are backwards compatible. This is addressed in this release, but means that anyone already serializing these classes will get a InvalidClassException
after upgrading to this version or later. The workaround is to migrate away from these classes before upgrading, and then optionally migrating back to fixed classes after upgrade (or not).
See section on migrating serializers in README and SerializerWithFallbackDeserializers
for hints on how to migrate serialization.
This only affects Java serialization.
scheduler.pause()
. Contributed by tkosgrabar