Mailing-List: contact dev-help@quarks.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@quarks.incubator.apache.org
Date: Thu, 26 May 2016 15:32:12 +0000 (UTC)
From: "Dale LaBossiere (JIRA)" <jira@apache.org>
To: dev@quarks.incubator.apache.org
Message-ID: <JIRA.12956204.1459874584000.304217.1464276732931@Atlassian.JIRA>
In-Reply-To: <JIRA.12956204.1459874584000@Atlassian.JIRA>
References: <JIRA.12956204.1459874584000@Atlassian.JIRA> <JIRA.12956204.1459874584517@arcas>
Subject: [jira] [Commented] (QUARKS-120) Counter oplet looks like a source
 for complex tuple type
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 26 May 2016 15:32:16 -0000


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

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 someth=
ing 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 e=
dges.  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 outgo=
ing.  OK.  But graph.js/addValueToEdges() is being called with a "counterMe=
trics" array that includes that RateMetric op.  A RateMetric shouldn't be p=
articipating 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 s=
ure yet if it's the runtime or Console.  This subgraph is part of the "Sour=
ce 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 u=
p.

> 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.d=
oc
>
>
> In the graph for TopologyTestBasic, a counter oplet appears to be a sourc=
e (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 exp=
ected?
> 130 is a counter oplet that looks like a source.
> 77 is a fanout=C2=AC (see View all oplet properties table below).
> There is tag "mcs1".=20
> See attachment for screen shots.
> {code}
> //**************************************************************=09  =20
>         //Source 2 using complex tuple type
>         //**************************************************************
>         Random r2 =3D new Random();
>         TStream<MyClass1> mc1 =3D t.poll(
>                 () -> new MyClass1(Double.toString(r2.nextGaussian()), =
=09=09=09=09=09                                          =20
>                         Double.toString(r2.nextGaussian()),r1.nextGaussia=
n()
>                 ),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.toStrin=
g()));
>         mc1.flatMap(tuple -> Arrays.asList(tuple.toString().split(" ")));
>         //An asString
>         TStream<String> mcs1 =3D mc1.asString().tag("mcs1");
>         mcs1.peek(tuple -> System.out.println(" mcs1_source2: " + tuple.t=
oString()));
>         List<TStream<String>> splits2 =3D 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)