[
https://issues.apache.org/jira/browse/QUARKS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250866#comment-15250866
]
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_r60499668
--- Diff: api/topology/src/main/java/quarks/topology/TStream.java ---
@@ -443,7 +443,7 @@ else if (WARNING.equals(lr.getLevel()))
Set<String> getTags();
/**
- * Add an alias for the stream.
+ * Set an alias for the stream.
* <p>
* The alias must be unique within the topology.
--- End diff --
I think it has to be that restrictive for things to remain sane. What you
say is true, but a TStream.alias() user has no idea or control over what
"types" may be registered by the runtime or others using an alias so they can't
predict or otherwise avoid collisions, right?
E.g., maybe some day poll() and map() register some mbean with the same
type, say, some logging mbean or such?
At a higher level I'm not really getting it wrt picking "type" or alias
names, or "ids" for that matter in order to generally avoid collisions since
the ControlService is documented as expecting to be used by application code as
well as the runtime. Seems like minimally more doc is needed in ControlService
for conventions for these. And right now the runtime uses unadorned values
like "job" and "periodic" for types - what's to prevent an ignorant user for
picking those to use for their own application specific controls?
> 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)
