[ 
https://issues.apache.org/jira/browse/QUARKS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194331#comment-15194331
 ] 

ASF GitHub Bot commented on QUARKS-8:
-------------------------------------

Github user vdogaru commented on a diff in the pull request:

    https://github.com/apache/incubator-quarks/pull/9#discussion_r56089774
  
    --- Diff: runtime/etiao/src/main/java/quarks/runtime/etiao/EtiaoJob.java ---
    @@ -51,6 +53,10 @@ public EtiaoJob(DirectGraph graph, String topologyName, 
ServiceContainer contain
             ControlService cs = container.getService(ControlService.class);
             if (cs != null)
                 cs.registerControl(JobMXBean.TYPE, getId(), getName(), 
JobMXBean.class, new EtiaoJobBean(this));
    +        
    +        this.jobs = (JobRegistry) 
container.getService(JobRegistryService.class);
    --- End diff --
    
    I considered the following alternatives:
       a) JobRegistry is an implementation class, then the runtime should 
register the registry, rather than the application. 
       b) JobRegistry has nothing specific to the etaio runtime, can be in its 
own module at the same level with JSONControl and JMXControl services. The 
JobRegistryService interface provides an add() method and is part of the same 
module.
    
    I think (b) has the advantage of modularity.


> Restart topology on uncaught exception
> --------------------------------------
>
>                 Key: QUARKS-8
>                 URL: https://issues.apache.org/jira/browse/QUARKS-8
>             Project: Quarks
>          Issue Type: New Feature
>          Components: Runtime
>            Reporter: Victor Dogaru
>            Assignee: Victor Dogaru
>              Labels: failure-recovery
>
> If a Quarks thread abruptly terminates due to an uncaught exception the 
> runtime shuts down. 
> A mechanism is needed to prevent the Quarks application from becoming 
> unavailable:
> * Have a monitor service which resubmits the topology in case it shuts down.
> * Restart the failed oplet. In the ETIAO runtime, a source and all downstream 
> oplet invocations (up to an Isolate) will execute in the same thread, so the 
> runtime needs to restart the failed path.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to