[
https://issues.apache.org/jira/browse/QUARKS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252012#comment-15252012
]
ASF GitHub Bot commented on QUARKS-131:
---------------------------------------
Github user dlaboss commented on a diff in the pull request:
https://github.com/apache/incubator-quarks/pull/86#discussion_r60595879
--- Diff: api/graph/src/main/java/quarks/graph/Connector.java ---
@@ -115,5 +115,27 @@ Licensed to the Apache Software Foundation (ASF) under
one
*
* @return set of tag values.
*/
- Set<String> getTags();
+ Set<String> getTags();
+
+ /**
+ * Set the alias for the connector.
+ * <p>
+ * The alias must be unique within the topology.
+ * The alias may be used in various contexts:
+ * <ul>
+ * <li>Runtime control services for the connector are registered with
this alias.</li>
--- End diff --
Sort of confusing since there are really 3 abstraction levels to the system
:-) Would changing "... the connector" => " the Connector" (talking about this
class not connectors in the sense of mqtt, iot, ...) or "this Connector" help
clarify?
[Maybe I'm just misreading your second sentence. There's nothing
stream/TStream specific about a control service nor ControlService. ]
At the API level users deal in terms of TStream.alias() - an alias for the
stream and from their perspective control services are registered for the
stream.
But at the graph level of the system, its a graph.Connector (the logical
equivalent of an output port / stream) that has the alias and services are
registered are for the Connector's alias. It has no direct knowledge of
TStream.
The oplet level, doesn't have any knowledge of TStream or Connector, it
just deals in Consumer for an output port. It needs to register the control
service with the alias from the "output port" (aka stream / Connector /
TStream). I'm particularly interested in a sanity check on the addition of
OutputContext to OpletContext. It, or something else, is needed for the oplet
to be able to get the alias to register mbean.
> need easy way to get PeriodicMXBean associated with a poll() invocation
> -----------------------------------------------------------------------
>
> Key: QUARKS-131
> URL: https://issues.apache.org/jira/browse/QUARKS-131
> Project: Quarks
> Issue Type: Improvement
> Reporter: Dale LaBossiere
> Assignee: Dale LaBossiere
>
> I think we're missing some API is missing to make this all usable.
> A Topology/TStream domain user needs an easy way to get the PeriodicMXBean
> for a particular Topology.poll() invocation.
> The PeriodicSource oplet implements PeriodicMXBean which allows changing the
> period.
> The only demonstrated use is by
> DirectJobTest.jobPeriodicSourceCancellation(), which iterates over the
> Topology's underlying graph for instanceof PeriodicSource oplet (it's the
> only ProcessSource oplet in the graph for this test).
> That's certainly not easy / convenient / nor in the "TStream" domain the user
> is mostly operating in.
> [~djd] [~vdogaru] what schemes for addressing this have already been
> considered / decided? Some sort of "control bean registry service" where a
> user gets to supply a name (e.g., to poll()) and the runtime registers the
> bean (e.g., PeriodicMXBean) under that name? If there's not a concrete plan
> lets work on that here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
