Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-4866

Failing Job Lock Time is not save correctly during Daylight Saving Hour

    Details

      Description

      If a retry cycle is used during the daylight saving hour, so for example the clock will be set back by one hour, the calculated lock time seems incorrect saved to the database.

      So if the lock time would be in the 02:25:00 CEST it is persisted as 02:25:00 CET.

      See failing test case:
      https://github.com/camunda/camunda-bpm-platform/commit/195d0b194785f4da08d0bd4338cede22190006db

        Issue Links

          Activity

          Hide
          askar.akhmerov Askar Akhmerov added a comment - - edited

          not sure that this is a problem, following JVM parameter would solve the problem

          -Duser.timezone=CEST
          

          value coming from the database to jdbc

          TIMESTAMP '2015-10-25 02:55:00.0'
          

          code returning wrong wrapped value

          new Date(sqlTimestamp.getTime())
          

          so timezone is changed on JVM layer forces conversion of timestamp into next timezone.

          The TIMESTAMP column was set to whatever the local time was on the machine executing the Java code. No time zone translation was performed.
          The TIMESTAMP WITH TIME ZONE column translated the time to whatever timezone the JDBC client was in.
          The TIMESTAMP WITH LOCAL TIME ZONE column also translated the time to whatever timezone the JDBC client was in.

          Show
          askar.akhmerov Askar Akhmerov added a comment - - edited not sure that this is a problem, following JVM parameter would solve the problem -Duser.timezone=CEST value coming from the database to jdbc TIMESTAMP '2015-10-25 02:55:00.0' code returning wrong wrapped value new Date(sqlTimestamp.getTime()) so timezone is changed on JVM layer forces conversion of timestamp into next timezone. The TIMESTAMP column was set to whatever the local time was on the machine executing the Java code. No time zone translation was performed. The TIMESTAMP WITH TIME ZONE column translated the time to whatever timezone the JDBC client was in. The TIMESTAMP WITH LOCAL TIME ZONE column also translated the time to whatever timezone the JDBC client was in.
          Hide
          roman.smirnov Smirnov Roman added a comment -

          Whenever a Lock Time or Due Date of a job is calculated, while the clock will be set back by one hour, e.g.

          "2018-10-28'T'02:47:00+0200" + 60 Minuten = "2018-10-28'T'02:47:00+0100"
          

          Then the job can be acquired by the job executor directly, without waiting one hour.

          In case of the Lock Time, it can happen that the same job is acquired multiple times by the Job Executor, so that the job is executed multiple times in parallel, e.g.

          "2018-10-28'T'02:55:00+0200" + 5 Minuten = "2018-10-28'T'02:00:00+0100"
          
          Show
          roman.smirnov Smirnov Roman added a comment - Whenever a Lock Time or Due Date of a job is calculated, while the clock will be set back by one hour, e.g. "2018-10-28'T'02:47:00+0200" + 60 Minuten = "2018-10-28'T'02:47:00+0100" Then the job can be acquired by the job executor directly, without waiting one hour. In case of the Lock Time, it can happen that the same job is acquired multiple times by the Job Executor, so that the job is executed multiple times in parallel, e.g. "2018-10-28'T'02:55:00+0200" + 5 Minuten = "2018-10-28'T'02:00:00+0100"
          Hide
          tobias.metzke Tobias Metzke added a comment -

          Evaluation:

          1. Database attributes containing date values do not contain timezone information in Camunda tables and dates are send as local dates by the JDBC calls we use. We do this to transparently use all supported databases, since not all databases offer a type with timezone information (e.g. for DB2 only on z/OS).
          2. Date values are saved without timezone information, meaning that 2018-10-28 02:47:00 CEST is saved as 2018-10-28 02:47:00 and when retrieved with timezone Europe/Berlin is ambiguous (could be 2018-10-28 02:47:00 CEST and 2018-10-28 02:47:00 CET since both points in time exist in this timezone), JDBC driver then chooses the 2018-10-28 02:47:00 CET value which is prior to the original value and therefore leads to unexpected behavior like a high load on the job executor since all new jobs are immediately due.
          3. This can be solved by
            1. using a different database type for date values, e.g. a numeric field that stores the milliseconds from epoch, BUT this introduces migration overhead for ALL customers, must be handled in the engine correctly for new and old schemas, and might introduce performance issues
            2. storing and reading all date values as UTC-based values transparently by using a custom myBatis type handler, BUT this introduces migration overhead for ALL customers since the current date values must be converted to UTC-based values
            3. disabling the job executor for the duration of DST switch ranges, BUT this might not be possible for all customer (e.g. if a certain job MUST be executed every hour)
            4. configuring the timezone used by the database and the application to be a DST-free (and therefore linear) timezone like UTC, BUT this might introduce migration overhead for customers and not be feasible for all customers

          At the moment, we will not fix anything in the engine since we consider the effort as not being justified.
          We will document this behavior and workarounds #3 (disable job executor) and #4 (use UTC in DB and app) in the official documentation.

          Show
          tobias.metzke Tobias Metzke added a comment - Evaluation: Database attributes containing date values do not contain timezone information in Camunda tables and dates are send as local dates by the JDBC calls we use. We do this to transparently use all supported databases, since not all databases offer a type with timezone information (e.g. for DB2 only on z/OS). Date values are saved without timezone information, meaning that 2018-10-28 02:47:00 CEST is saved as 2018-10-28 02:47:00 and when retrieved with timezone Europe/Berlin is ambiguous (could be 2018-10-28 02:47:00 CEST and 2018-10-28 02:47:00 CET since both points in time exist in this timezone), JDBC driver then chooses the 2018-10-28 02:47:00 CET value which is prior to the original value and therefore leads to unexpected behavior like a high load on the job executor since all new jobs are immediately due. This can be solved by using a different database type for date values, e.g. a numeric field that stores the milliseconds from epoch, BUT this introduces migration overhead for ALL customers, must be handled in the engine correctly for new and old schemas, and might introduce performance issues storing and reading all date values as UTC-based values transparently by using a custom myBatis type handler, BUT this introduces migration overhead for ALL customers since the current date values must be converted to UTC-based values disabling the job executor for the duration of DST switch ranges, BUT this might not be possible for all customer (e.g. if a certain job MUST be executed every hour) configuring the timezone used by the database and the application to be a DST-free (and therefore linear) timezone like UTC, BUT this might introduce migration overhead for customers and not be feasible for all customers At the moment, we will not fix anything in the engine since we consider the effort as not being justified. We will document this behavior and workarounds #3 (disable job executor) and #4 (use UTC in DB and app) in the official documentation.

            People

            • Assignee:
              nikola.koevski Nikola Koevski
              Reporter:
              sebastian.menski Sebastian Menski
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development