sorry for taking so long getting back to you on this. I think it depends entirely on the context of your application on whether execution overlap is desireable. I would guess there are applications that your patch would break since they depend on the overlap behaviour (the idea behind a time scheduler is that it guarantees something happens at a particular time, innit). Do you agree?
Hence I think it's not a wise idea to apply it. However, if you could generate a patch against the defaultscheduler that makes the methods you need to override protected, rather than private, that is something we can do. Sounds like a plan?
cheers,
- Leo
Stefan Seifert wrote:
I want to use the TimeScheduler componente in a phoenix-based server environment and, for some reasons, need a slightly different behaviour of the TimeSchedule component concering periodic triggers:
In the current implementation the target is triggerd in a separate thread. For this reason, the next trigger is triggerd with a duration relative to the *start* of the target execution. This is a problem with long running tasks in this target execution, because several executions would overlap (or - using synchronized - queue up and executly immediately several times).
Attached is a patch that corrects this: rescheduleEntry is called when the separate thread for target executions finishes, not when it starts.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
