Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring Boot: always-persist-timestamp-in-utc has no effect #487

Closed
GeorgEchterling opened this issue May 15, 2024 · 2 comments · Fixed by #490
Closed

Spring Boot: always-persist-timestamp-in-utc has no effect #487

GeorgEchterling opened this issue May 15, 2024 · 2 comments · Fixed by #490
Labels
bug released Issue has been released

Comments

@GeorgEchterling
Copy link
Contributor

Expected Behavior

Setting the Spring property db-scheduler.always-persist-timestamp-in-utc=true should create an AutodetectJdbcCustomization with persistTimestampInUTC = true.

Current Behavior

Setting db-scheduler.always-persist-timestamp-in-utc=true has no effect on the created AutodetectJdbcCustomization. The JdbcCustomization must be manually corrected via a DbSchedulerCustomizer.

In the case of MariaDB, the "utc_warning" still gets logged. It is also impossible to prevent this warning (except by silencing the logs), since even overriding the JdbcCustomization with a corrected version doesn't prevent the DbSchedulerAutoConfiguration from temporarily creating the incorrect variant.


For bug reports

Steps to Reproduce the bug

  1. Use db-scheduler-spring-boot-starter
  2. Use MariaDB
  3. Set db-scheduler.always-persist-timestamp-in-utc=true
  4. The "utc_warning" will appear and the Scheduler will incorrectly not use UTC timestamps.

Context

  • DB-Scheduler Version : 14.0.0
  • Java Version : 21
  • Spring Boot (check for Yes) : [x]
  • Database and Version : MariaDB 10.11.5

Logs

2024-05-15T12:08:44.768+02:00  INFO 134292 --- [  restartedMain] c.g.k.s.b.a.DbSchedulerAutoConfiguration : Creating db-scheduler using tasks from Spring context: [RecurringTask name=alert-orphaned-files, onComplete=OnCompleteReschedule with CronSchedule pattern=0 0 5 10 * ?, cronStyle=SPRING53, zone=Europe/Berlin, RecurringTask name=alert-pending-exports, onComplete=OnCompleteReschedule with CronSchedule pattern=0 30 6 * * ?, cronStyle=SPRING53, zone=Europe/Berlin]
2024-05-15T12:08:44.774+02:00  INFO 134292 --- [  restartedMain] c.g.k.s.j.AutodetectJdbcCustomization    : Detected database MariaDB.
2024-05-15T12:08:44.774+02:00  INFO 134292 --- [  restartedMain] c.g.k.s.j.AutodetectJdbcCustomization    : Using MariaDB jdbc-overrides.
2024-05-15T12:08:44.774+02:00  WARN 134292 --- [  restartedMain] c.g.k.s.j.A.utc_warning                  : MariaDB-schema does not support persistent timezones. It is recommended to store time in UTC to avoid issues with for example DST. For first time users, use setting 'alwaysPersistTimestampInUtc' to achieve this. Users upgrading from a version prior to v14.0.0 can either silence this logger, or perform a controlled upgrade to UTC timestamps. All old instances of the scheduler must be stopped and timestamps migrated to UTC before starting again, using 'alwaysPersistTimestampInUtc=true'.
2024-05-15T12:09:03.291+02:00  INFO 134292 --- [  restartedMain] c.g.k.scheduler.SchedulerBuilder         : Creating scheduler with configuration: threads=10, pollInterval=10s, heartbeat=300s enable-immediate-execution=false, table-name=scheduled_tasks, name=dev-scheduler
@GeorgEchterling
Copy link
Contributor Author

I think this is caused by this part of DbSchedulerAutoConfiguration, which was added in #357:

    // Use custom JdbcCustomizer if provided.
    builder.jdbcCustomization(
        customizer
            .jdbcCustomization()
            .orElse(new AutodetectJdbcCustomization(transactionalDataSource)));

The default AutodetectJdbcCustomization is created without receiving the configured value of alwaysPersistTimestampInUTC. This also prevents the correct default in SchedulerBuilder#build from working, since the jdbcCustomization is always set in the auto-configuration:

    final JdbcCustomization jdbcCustomization =
        ofNullable(this.jdbcCustomization)
            .orElseGet(
                () -> new AutodetectJdbcCustomization(dataSource, alwaysPersistTimestampInUTC));

I think this can be fixed by simply removing the default jdbcCustomization in DbSchedulerAutoConfiguration. I.e.:

    // Use custom JdbcCustomizer if provided.
    customizer.jdbcCustomization().ifPresent(builder::jdbcCustomization);

GeorgEchterling pushed a commit to GeorgEchterling/db-scheduler that referenced this issue May 16, 2024
kagkarlsson pushed a commit that referenced this issue May 28, 2024
…#490)

## Brief, plain english overview of your changes here
I've changed the Spring Boot auto-configuration to ensure that the
`jdbcCustomization` default does not override the configured
`alwaysPersistTimestampInUTC` default. The previous `orElse` part is not
necessary because the correct `jdbcCustomization` default later gets
applied in `SchedulerBuilder#build`.

## Fixes
Fixes #487 


## Reminders
- [ ] Added/ran automated tests
  - I don't know how to add an efficient test for this.
- I ran the tests but I got an unrelated error in an Oracle
compatibility test, even without this change.
- [ ] Update README and/or examples
  - I don't think this is relevant.
- [ ] Ran `mvn spotless:apply`
  - This only changed unrelated code.

---
Co-authored-by: Georg Echterling <g.echterling@jobware.de>
@kagkarlsson
Copy link
Owner

🎉 This issue has been resolved in v14.0.1 (Release Notes)

@kagkarlsson kagkarlsson added the released Issue has been released label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug released Issue has been released
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants