[
https://issues.apache.org/jira/browse/TWILL-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597039#comment-14597039
]
Henry Saputra edited comment on TWILL-116 at 6/23/15 2:54 AM:
--------------------------------------------------------------
Hi Terence, thank you for the comments, let me try to address them:
1. I suppose you meant the updateRunnableState(s) methods? Yes, the main
purpose of the RunnableStateCommand class is to have a place to hang the
Callable for callback once the operation has be done. I guess we could just use
the Command and its builder to send String commands. As for using Future, yes I
think that would be good idea to have it as return values.
2. The plan was to have it pluggable for Apache Twill, which by default will
just store it in memory. The number of history records would be bounded for
memory based store but should be overridden for disk-based store.
3. I will introduce new interface to allow specific type for the value in the
list. Will update the design document to reflect this.
4. Yes, it will still through ZK message mechanism but the ZK watch will be set
in the AM via ApplicationMasterService. The lifecycle updates will then be done
via NMClient from the ApplicationMasterService to NM.
5. The initial proposal is to apply the update state command to all instances
for a runnable. But seeing message from @Keith that he has use case to restart
particular instance so may need some thinking on how to do it.
was (Author: hsaputra):
Hi Terence, thank you for the comments, let me try to address them:
1. I suppose you meant the updateRunnableState(s) methods? Yes, the main
purpose of the RunnableStateCommand class is to have a place to hang the
Callable for callback once the operation has be done. I guess we could just use
the Command and its builder to send String commands. As for using Future, yes I
think that would be good idea to have it as return values.
2. The plan was to have it pluggable for Apache Twill, which by default will
just store it in memory. The number of history records would be bounded for
memory based store but should be overridden for disk-based store.
3. I will introduce new interface to allow specific type for the value in the
list. Will update the design document to reflect this.
4. Yes, it will still through ZK message mechanism but the ZK watch will be set
in the AM via ApplicationMasterService. The lifecycle updates will then be done
via NMClient from the ApplicationMasterService to NM.
5. The initial proposal is to apply the update state command to all instances
for a runnable. But just message from Keith that he has use case to restart
particular instance so may need some thinking on how to do it.
> Support for start/stop/restart of a runnable in an application
> --------------------------------------------------------------
>
> Key: TWILL-116
> URL: https://issues.apache.org/jira/browse/TWILL-116
> Project: Apache Twill
> Issue Type: New Feature
> Components: core
> Reporter: Albert Shau
> Assignee: Henry Saputra
> Fix For: 0.6.0-incubating
>
> Attachments: TWILL-116-design.pdf
>
>
> Once an application is running, it would be good to be able to stop, start,
> and restart a specific runnable of the application without affecting other
> runnables.
> For example, I may be running multiple services in a single application, with
> each service as a different runnable. One of my services gets into an invalid
> state. I now want to restart just that runnable and not the other ones that
> are running properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
