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.
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.
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
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.
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.
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.
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.
Dimitris, thank you very much for your time and providing me a direction.