7 Replies Latest reply on Jan 23, 2006 1:16 PM by guy_rouillier

    Varia scheduler takes a very long nap

    guy_rouillier

      We have a large application that is completely schedule driven. We use the varia scheduler to run the schedules. We do very verbose logging; at the bottom of this note is a snippet from yesterday. Notice that it took a 4 1/2 hr break starting at 16:25. This most certainly is not appropriate. We have schedules that go off every 5 minutes and others that go off every 15 minutes. The line at 20:00:17 is actually the termination of a method that started 3 hrs earlier, so really the shedulers didn't start working again until 21:09.

      Are there known issues with the varia scheduler not running schedules for long periods of time? Would it be better for me to switch to Quartz?

      2006-01-17 16:25:27,024 INFO [FileGroupLockMonitor] readDirectory Thread 106107: Thread[Timer-1939,5,jboss] Directory: /data/java/rodent/alcatelFiles/unprocessed pattern: act.*\.xml\.gz
      2006-01-17 16:25:27,026 INFO [FileTxrCollectorTimetra]
      FileTxrCollectorTimetra.getStats(): elapsed time in seconds => 524.0
      2006-01-17 20:00:17,304 INFO [RodentBean] beginning date Mon Jan 16 00:00:00 GMT 2006, end date Tue Jan 17 00:00:00 GMT 2006
      2006-01-17 21:09:45,029 INFO [SNMPCollectorSummit] polled all devices
      2006-01-17 21:09:45,034 INFO [FileGroupLockMonitor] readDirectory Thread 36: Thread[Timer-3,5,jboss] Directory: /data/java/rodent/alcatelFiles/unprocessed pattern: act.*\.xml\.gz

        • 1. Re: Varia scheduler takes a very long nap
          dimitris

          I suspect this may be due to the scheduler working in a fixed-period mode rather than fixed-rate mode. If this is the case, you could spawn a thread to do the actual processing.

          • 2. Re: Varia scheduler takes a very long nap
            guy_rouillier

            Dimitris, thank you for the reply. I want to make sure I understand what you are saying. I've seen in the past when the scheduler tries to start up an MBean method that is already running from a previous execution; we print out a message in this case "already running" and simply terminate. So I know the scheduler is capable of executing its schedules on fixed 5 minute intervals (for example.) Sometimes it seems it just doesn't. How does the fixed period vs fixed rate figure into this? Processing overlap clearly didn't happen in this case, as the MBean methods that get executed every 5 minutes weren't running at all during this 4 hour window.

            • 3. Re: Varia scheduler takes a very long nap
              guy_rouillier

              Darn, this is happening much more frequently than I realized:

              2006-01-21 10:56:31,895 INFO [FileTxrCollectorTimetra]
              FileTxrCollectorTimetra.getStats(): elapsed time in seconds => 6986.0
              2006-01-21 15:23:34,992 INFO [RodentBean] beginning date Fri Jan 20 00:00:00 GMT 2006, end date Sat Jan 21 00:00:00 GMT 2006
              2006-01-21 17:24:16,975 INFO [SNMPCollectorSummit] polled all devices

              The job above that finished at 15:23:34 was started at 2006-01-21 10:25:10,306, even though the schedule for it looks like this:

              1/21/2005 3:00 AM
              86400000
              -1

              Is this because the "next" iteration starts 86400000 milliseconds after the previous iteration terminates? Should I rearrange the logic so that the MBean method just starts up a thread and returns immediately? I think this is what you were suggesting. I'm gathering that having an MBean method take 5 hrs to complete is not a good thing.

              • 4. Re: Varia scheduler takes a very long nap
                guy_rouillier

                Oops, sorry about that, looks like the forum software swallowed the XML tags. In that prior post, the three listed values are all attribute tags, for InitialStartDate, SchedulePeriod and InitialRepetitions, respectively.

                • 5. Re: Varia scheduler takes a very long nap
                  guy_rouillier

                  Sorry for so many posts at once, my brain is finally kicking in after I overdosed on sugar. I think I'm understanding what you may have meant by fixed period vs fixed rate: X milliseconds after last interation finishes vs every X milliseconds. But even if that was the case, at worst I should see the 5 minute jobs being restarted 5 minutes after the last iteration finished. That wouldn't seem to explain the 5-hr lapse in my first post today where I'm not seeing any activity at all.

                  Appreciate any pointers you can give. This application determines our company's revenue and is therefore critical for me to get working properly.

                  • 6. Re: Varia scheduler takes a very long nap
                    dimitris

                    Yes, spawn a thread (if the previous run is not still executing) and do the job there if you want more accurate scheduling. If I remember correclty, this scheduler doesn't have a thread pool, so the same thread is used to execute a schedule. If you hold up this thread 5 hours, your are toast.

                    • 7. Re: Varia scheduler takes a very long nap
                      guy_rouillier

                      Dimitris, thank you very much for your time and providing me a direction.