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)