You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by "Dale LaBossiere (JIRA)" <ji...@apache.org> on 2016/06/03 15:37:59 UTC
[jira] [Created] (QUARKS-195) Metrics.{counter,rateMeter}()
shouldn't use TStream.pipe()
Dale LaBossiere created QUARKS-195:
--------------------------------------
Summary: Metrics.{counter,rateMeter}() shouldn't use TStream.pipe()
Key: QUARKS-195
URL: https://issues.apache.org/jira/browse/QUARKS-195
Project: Quarks
Issue Type: Bug
Components: API
Reporter: Dale LaBossiere
Priority: Minor
Add `TStream.peek(Peek<T>)` and change `Metrics.counter(TStream)` and `Metrics.rateMeter(TStream)` to use it instead of `pipe()`.
Using pipe() isn't appropriate as these are Peek ops and it's partially responsible for the effect reported in QUARKS-189. Changing to peek() will eliminate one of the two extra injected CounterOp and will eliminate the single extra StreamScope.
The growing number of "oplet" based analogs to the "function" based methods makes me wonder if the oplet ones should be broken out into another interface that TStream implements (`OpletTStream`?). It would contain the current `pipe(Pipe)`, `fanin(FanIn,List)`, `sink(Sink)`, and the new `peek(Peek)`, and any others that may be needed in the future - e.g., a `split(Split)` and/or one that can handle multiple iports and oports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)