[
https://issues.apache.org/jira/browse/QUARKS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194002#comment-15194002
]
ASF GitHub Bot commented on QUARKS-8:
-------------------------------------
Github user ddebrunner commented on a diff in the pull request:
https://github.com/apache/incubator-quarks/pull/9#discussion_r56062476
--- 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 --
Maybe then it's the sole responsibility of the runtime to register a
JobRegistry and thus JobRegistry would not be a public class, but instead an
implementation detail
Then it would not be expected that external code registers a
JobRegistryService .
> 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)
