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 <[email protected]> > 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" <[email protected]>: > > 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 <[email protected]> wrote: >> >> >>> On Sep 20, 2017, at 1:32 PM, Christofer Dutz <[email protected]> >>> 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 > > >
