edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale LaBossiere (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QUARKS-120) Counter oplet looks like a source for complex tuple type
Date Thu, 26 May 2016 15:32:12 GMT

    [ https://issues.apache.org/jira/browse/QUARKS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302256#comment-15302256
] 

Dale LaBossiere commented on QUARKS-120:
----------------------------------------

PR-166 included console changes to propagate a FanOut's input stream metric to its output
streams for proper rendering of them.  Hmm... there's something about this app/graph that
the new code gags on.  Ugh. Looking into it...

The new code expects that a counter metric has both incoming and outgoing edges.  TopologyTestBasic
ends up causing that to be violated in two ways:
a) OP_13 is a RateMeter that's added at the end of a stream, hence no outgoing.  OK.  But
graph.js/addValueToEdges() is being called with a "counterMetrics" array that includes that
RateMetric op.  A RateMetric shouldn't be participating in these stream-width activities.
 I have to keep looking into this to determine where the appropriate changes should be.
b) OP_113 is a CounterOp that has no incoming edges.  This is wrong.  Not sure yet if it's
the runtime or Console.  This subgraph is part of the "Source 2" flow.  I'll continue to pull
on this thread.

In the mean time I'll deliver changes so the graph rendering doesn't blow up.

> 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
>            Reporter: May Wone
>            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)

Mime
View raw message