Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-8929

Race condition if timers overlap due to long running execution and short schedules if database persistence is used

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 11.0.0.Beta1
    • None
    • EJB
    • None

    • Configure DB persistence for timers as file-persistence will not have a persistence check for shouldRun to lock the timer execution.

    • Hide

      Create a Simple Bean @Singleton and use a method like this:

      @Schedule(second = "*/1", minute = "*", hour = "*", persistent = true)
      private void longRunning4parallelExecution() {
      LOGGER.info("Start long running scheduled method");
      int sec = 988;
      LOGGER.info("sleeping " + sec + " milli seconds.");
      try

      { Thread.sleep(sec); }

      catch (InterruptedException e) {}
      LOGGER.info("Finished executing concurrent schedule");
      }

      The timer show often concurrent WARN messages and should stuck after a few minutes running

      Show
      Create a Simple Bean @Singleton and use a method like this: @Schedule(second = "*/1", minute = "*", hour = "*", persistent = true) private void longRunning4parallelExecution() { LOGGER.info("Start long running scheduled method"); int sec = 988; LOGGER.info("sleeping " + sec + " milli seconds."); try { Thread.sleep(sec); } catch (InterruptedException e) {} LOGGER.info("Finished executing concurrent schedule"); } The timer show often concurrent WARN messages and should stuck after a few minutes running

      If timers (here calendar timer) are running longer than scheduled, or the schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the updates for persistence overlap.

      The issue seems that the task(1) try to finish the timer and task(2) is about to start but see the concurrency.
      The DB is updated with the 'old' next timeout, but the internal Timer instance will be updated with the next possible schedule due to a race condition between the two threads updating the object.

        1. server1.log
          39 kB
        2. server-extract.log
          19 kB

              rhn-support-wfink Wolf Fink
              rhn-support-wfink Wolf Fink
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: