Eric van der Vlist wrote:
I have some questions about the scheduler processor:
* What's happening when synchronized is set to false and another
task with the same name is already running?
* Is the previous instance of the task stopped or can several
instances of a same task run at the same time?
It should just run in parallel. I am saying "should" quickly looking at the code (I didn't write it). That's also the behavior I would expect.
On the other hand, if "synchronized" is set to true, the task simply doesn't run, which is not quite what I would call synchronization.
* What's happening when an exception is raised in a task?
It's just going to fail.
* Is this exception handling configurable?
Not at the moment. I think this should be best handled by exceptions in XPL.
* Why are the inputs of the task embedded in the config input?
Wouldn't that make more sense to define them as... inputs?
Because there are two distinct steps:
o Configuring the scheduler, which may occur, for example when the application context is started.
o Running the task, which may happen at a much later time, and in a different context.
When the task runs, it should *then* read its inputs, as opposed to using inputs available when the scheduler was initialized. This is also consistent with the way the main processor and error processor are configured in OPS.
* Is that an error to try to stop a task that isn't running?
Looking at the code, it looks like not. Which is also the correct behavior I think, for synchronization reasons (e.g. the task may have just terminated on its own).
* What happens exactly when a command is stopped?
The task runs to completion. "If the task has been scheduled for one-time execution and has not yet run, or has not yet been scheduled, it will never run. If the task has been scheduled for repeated execution, it will never run again. (If the task is running when this call occurs, the task will run to completion, but will never run again.)"
* Are there any risk that a task is stopped in the middle of a
processing?
No.
* If yes, shouldn't it be possible to define transaction like
sections in a pipeline which should be completed before a task
can be stopped?
See above.
* Wouldn't it be fine if the scheduler processor had a third
command that outputs the list of running tasks?
Maybe a list of defined tasks and their current status.
http://sourceforge.net/tracker/index.php?func=detail&aid=1116191&group_id=116683&atid=675663
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
