[
https://issues.apache.org/jira/browse/QUARKS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15304773#comment-15304773
]
Dale LaBossiere commented on QUARKS-120:
----------------------------------------
I'm backing off of my stance for "a" above. RateMetric (a type of counter that
also yields an actual tuple count like CounterOp) is a sensible candidate for
establishing flow counts on edges. e.g., imagine a mode where the user wanted
RateMetric injection instead of CounterOp. The net is it's reasonable for a
(non-injected) "counter metric" to not have any outgoing edges -- and graph.js
is handling that case after other recent deliveries.
"b", is a runtime bug. The console is accurately rendering the info its given
(and it's not the type wrappers / Json processing).
I'm changing the component to "Runtime". I'm also sure it's not the tuple type
that responsible for any of this so I'm going to tweak the subject.
This logically 4-way fanout sequence causes the problem:
```
0 s = t.poll()
1 s.peek()
2 s.modify() (aka map)
3 s.peek()
4 s.flatmap()
```
It's really only a 2way fanout because peeks are handled specially, internally
"the stream" gets a peek inserted before its end; the stream always gets
extended to include the peek.
The above (after CounterOp and StreamScope injection -- not yet sure if the
injection is part of the problem) is yielding two disjoint flows:
```
poll -> peek -> peek -> Counter -> StreamScope -> map(modify)
CounterOp -> StreamScope -> flatmap
```
instead of:
```
poll -> peek -> peek -> Counter -> SS -> FanOut --> map // injectors don't
inject on FanOut outputs
\-> flatmap
```
The investigation continues...
> Counter oplet looks like a source for complex tuple type
> --------------------------------------------------------
>
> Key: QUARKS-120
> URL: https://issues.apache.org/jira/browse/QUARKS-120
> Project: Quarks
> Issue Type: Bug
> Components: Console, Runtime
> Reporter: May Wone
> Assignee: Dale LaBossiere
> Priority: Minor
> Attachments: CounterAsSourceComplexTupleType.doc, CounterSource.doc
>
>
> In the graph for TopologyTestBasic, a counter oplet appears to be a source
> (i.e. there's no other oplet pointing to the counter oplet). This looks odd
> to me - is this expected?
> Note this source uses a complex tuple type, i.e. a tuple is a Java object.
> The oplets 130, 77, 76 look odd - is this graph starting at oplet 130
> expected?
> 130 is a counter oplet that looks like a source.
> 77 is a fanout¬ (see View all oplet properties table below).
> There is tag "mcs1".
> See attachment for screen shots.
> {code}
> //**************************************************************
> //Source 2 using complex tuple type
> //**************************************************************
> Random r2 = new Random();
> TStream<MyClass1> mc1 = t.poll(
> () -> new MyClass1(Double.toString(r2.nextGaussian()),
>
> Double.toString(r2.nextGaussian()),r1.nextGaussian()
> ),100, TimeUnit.MILLISECONDS).tag("mc1");
> mc1.peek(g -> System.out.print(g.toString()));
> mc1.modify(tuple -> new MyClass1(tuple.getS1() + "a1 b1 c1 d1 ",
> tuple.getS2() +" e1 f1 g1 h1 ", tuple.getD1() +1) );
> mc1.peek(tuple -> System.out.println("MyClass1: " +
> tuple.toString()));
> mc1.flatMap(tuple -> Arrays.asList(tuple.toString().split(" ")));
> //An asString
> TStream<String> mcs1 = mc1.asString().tag("mcs1");
> mcs1.peek(tuple -> System.out.println(" mcs1_source2: " +
> tuple.toString()));
> List<TStream<String>> splits2 = mcs1.split(2, tuple -> {
> switch (tuple.toString().charAt(0)) {
> case '-': //negative numbers
> return 0;
> default: //everything else
> return 1;
> }
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
