Github user vdogaru commented on a diff in the pull request:
https://github.com/apache/incubator-quarks/pull/9#discussion_r56062002
--- 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 --
Thanks for catching this. My initial thinking was that a
JobRegistryService provides restricted functionality to the application code:
query, subscribe to job changes, and remove jobs, while **adding** jobs to the
registry is the responsibility of the runtime, which would directly call the
service implementation. A job is registered with a CONSTRUCTED state when a
DirectTopology is created, then it changes to RUNNING when the topology is
successfully submitted. Allowing application code to register jobs might clash
with the current implementation if applications add jobs already registered by
the runtime.
Currently the JobRegistryService docs indicate "registration" of Jobs as
well, but there is no add() method, which is confusing. Which of the following
is preferable?
1. JobRegistryService restricted to job query / removal (I'll update the
javadocs accordingly.)
2. Add registration to JobRegistryService.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
