edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: maven-cvt: console regressions
Date Mon, 25 Sep 2017 12:15:36 GMT
Hi Dale,

Argh! … ok that seemed to be so obviously wrong that my brain didn’t even seem to remember
“fixing” that.
Maybe I shouldn’t delegate fixing things to my co-processor ;-)

But it does show that it might be good to start doing, what I had introduced for the Flex
project. As soon as we merge things back, I think it would be a good idea to start run something
that utilizes the entire stack and verified via Selenium that the console output is as desired.

Chris


Am 25.09.17, 13:55 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:

    The problem was introduced here: https://github.com/apache/incubator-edgent/pull/309/commits/78a3e6fdc935993a5c0445e16e732ae25bbc6b52
    obj.opId was set correctly on line 52 (from op.opId).  After the change the value (now
from met.opId) I believe ended up being null which subsequently messed up other processing.
 Why the original no-op assignment was there… who knows?  :-)
    
    — Dale
    
    
    > On Sep 21, 2017, at 7:52 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
    > 
    > Hi Dale,
    > 
    > could you please sum up what the problem was? I did see you simplifying some of the
code, but couldn’t pin-point the individual change that fixed things.
    > 
    > Chris
    > 
    > 
    > 
    > Am 20.09.17, 23:56 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:
    > 
    >    I just delivered the fix for the two regressions.  See its comment for details.
    >    I think we can claim the console is operational again!
    > 
    >    — Dale
    > 
    >> On Sep 20, 2017, at 5:14 PM, Dale LaBossiere <dml.apache@gmail.com> wrote:
    >> 
    >> 
    >>> On Sep 20, 2017, at 1:32 PM, Christofer Dutz <christofer.dutz@c-ware.de>
wrote:
    >>> ...
    >>> I’m sure that is the reason for this. I did investigate that problem a
wile yesterday and I found out that the MBean the ConsoleMetricsServlet->MetricsUtil (line
105) is using to generate the output returns “long” instead of “counter” … but I
have to admit that I have no Idea why.
    >>> 
    >>> Will investigate tomorrow ;-)
    >> 
    >> I found another regression.  The hover on a union oplet incorrectly reports the
output tuple count - it’s not the sum.
    >> It’s demonstrable with the ConsoleWaterDetector sample (suspect caused by the
same problem causing the other regression):
    >> 
    >> cd samples
    >> mvn package
    >> cd console
    >> ./run-samples.sh ConsoleWaterDetector
    >> 
    >> I did a review of the cleanup changes that had been made to MetricsUtil.java
and found one problem though fixing it didn’t address either of these regressions.  I’m
delivering more cleanup of it.
    >> 
    >> — Dale
    > 
    > 
    > 
    
    

Mime
View raw message