These mechanisms depend on the director you use at the top level.
The Manager class ($PTII/ptolemy/actor/Manager) provides the basic
hooks for pausing and stopping a model. These methods delegate
to the top-level director. On a "pause" command, the director
will complete the current "iteration" and then return control
to the manager.  What is meant by an "iteration" will depend
on the director. See the director documentation.

On pausing, the Manager does not do anything to enable a
restart in a new process. In principle, you could subclass
Manager so that it serializes the model state and stores that.
However, I suspect it would be pretty tricky to get that right.

Hope this helps.
Edward


On 7/4/11 10:17 PM, Madhavi Tikhe wrote:
Hi

I need some information about the workflow execution control options
like stop, pause and resume.

1.If I have a workflow which submits jobs to cluster (JobManager,
JobCreate), and I want to pause the workflow execution, is it possible?
What is the expected behavior? After I pass on the command to
stop/pause, will the kepler abort the entire execution or will it finish
the currently processing actors and then stop?

2.If I pause a workflow execution today, will I be able to resume the
workflow execution after a week? In this case, how the data that is
processed before pausing the workflow maintained?

3.Is it possible to start/pause/resume a workflow from command line? How
do I get a workflow Id?

4.Lastly, where can I find any detail documentation of these control
features stop/pause/resumt?

Thanks in advance for the help,

Madhavi

DISCLAIMER ========== This e-mail may contain privileged and
confidential information which is the property of Persistent Systems
Ltd. It is intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient, you are
not authorized to read, retain, copy, print, distribute or use this
message. If you have received this communication in error, please notify
the sender and delete all copies of this message. Persistent Systems
Ltd. does not accept any liability for virus infected mails.



_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

<<attachment: eal.vcf>>

_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

Reply via email to