Approvals: 0/1
[01:34:59] *** ChanServ sets mode: +o temporalfox
[11:39:25] <tsegismont> cescoffier, hi, the Hawkular Metrics 0.9 upgrade has been merged into Hawkular repo https://github.com/hawkular/hawkular/pull/631
[11:40:09] <tsegismont> The image you use should be soon released to include the “group by” bugfix you hit
[11:40:23] <cescoffier> tsegismont : Great !
[13:20:11] <kislo_metal> Hi all
[13:20:33] <kislo_metal> have a question regrading vertx-unit 3.2.0
[13:21:00] <kislo_metal> what maven repository should I use for it ?
[13:27:36] <kislo_metal> any one?
[13:36:54] <Sticky_> maven central
[13:40:33] <kislo_metal> I see only 3.1.0 version there - http://mvnrepository.com/artifact/io.vertx/vertx-unit http://repo1.maven.org/maven2/io/vertx/vertx-unit/
[13:42:33] <kislo_metal> vertx-unit has version 3.2.0-SNAPSHOT now (what is the correct repository for snapshot versions, is there such ?)
[14:04:07] <cescoffier> kislo_metal the 3.2.0 is not release yet
[14:04:19] <cescoffier> kislo_metal you need to use the 3.2.0-SNAPSHOT
[14:39:22] <cescoffier> tsegismont : are you around ?
[14:39:29] <tsegismont> yep
[14:40:06] <cescoffier> I'm looking at your changes in the vertx-monitor
[14:40:10] <cescoffier> you have added host and port to the options
[14:40:25] <cescoffier> but they are not related to the HTTPOptions, is it on purpose ?
[14:43:00] <tsegismont> yes, it was like that in the beginnig
[14:43:34] <tsegismont> Then when I added the httpOptions field (in order to support configuration of the http client, in particular ssl)
[14:44:12] <tsegismont> I thought that I could simply put host/port config in defaultHost and defaultPort fields
[14:44:57] <tsegismont> But then when you use it, it feels a bit awkward
[14:45:36] <cescoffier> yes I agree
[14:45:37] <tsegismont> {enabled:true, httpOtions: {defaultHost: hawkularhost, defaultPort: hawkularport}}
[14:45:50] <cescoffier> so, the only things missing here (I'm adding it) it's 'enable'
[14:45:53] <tsegismont> that's why I moved back the parameters to top level
[14:46:04] <tsegismont> at which level?
[14:46:21] <tsegismont> isn't enabled field already in VertxOptions class?
[14:46:32] <tsegismont> sorry, VertxMetricsOptions
[14:47:51] <tsegismont> cescoffier, io.vertx.core.metrics.MetricsOptions#enabled
[14:48:05] <tsegismont> VertxHawkularOptions extends MetricsOptions
[14:48:40] <cescoffier> yes, but when we configure it from the command line, it does not invoke the parent class
[14:49:22] <tsegismont> ha
[14:49:35] <tsegismont> I need to take a look at command line usage
[14:49:59] <tsegismont> I must admit I only work with embedded fatjar mode
[14:50:06] <cescoffier> there is a mapping between service properties and metrics options
[14:51:21] <cescoffier> for instance: -Dvertx.metrics.options.enabled=true -Dvertx.metrics.options.host=192.168.99.100 -Dvertx.metrics.options.port=8090 -Dvertx.metrics.options.tenant=default -Dvertx.metrcs.options.prefix=hk-bridge -Dvertx.metrics.options.batchDelay=10
[14:54:44] <tsegismont> I understand
[14:55:00] <cescoffier> first PR opened
[14:55:24] <tsegismont> shouldn't the cli arg mapper check parent class properties?
[15:00:40] <cescoffier> tsegismont : Yes, it's done in vert.x core, I'm going to check how this is done
[15:05:49] <cescoffier> tsegismont : ah ah ah …. not funny. It's in the launcher stuff I did (I've copied the previous way, should have changed it)
[15:07:16] <tsegismont> hum?
[15:07:28] <cescoffier> tsegismont : the setter from the parent class not called
[15:07:39] <tsegismont> ha
[15:09:39] <cescoffier> tsegismont : so it will be fixed in core, but to chain the calls, would be good to have it in HawkularOptions too
[15:10:06] <cescoffier> tsegismont only the setter is required
[15:10:18] <tsegismont> agreed
[15:13:56] <cescoffier> tsegismont : the fix is part of https://github.com/eclipse/vert.x/pull/1183
[15:15:43] <cescoffier> tsegismont : PR updated
[15:19:25] <tsegismont> cescoffier, merged, thanks!
[15:26:54] <cescoffier> tsegismont : thanks !
[15:27:06] <cescoffier> tsegismont : next PR is coming….
[15:36:59] <rajith> purplefox: I took a stab at floating a proposal :)
[16:15:08] <gemmellr> chirino: purplefox: rajith: I put up a new vertx-proton PR with some changes around sender+reciever creation
[16:15:18] <gemmellr> partly to ease that and as a step towards doing some error handling
[16:15:22] <gemmellr> https://github.com/vert-x3/vertx-proton/pull/7
[16:15:49] <cescoffier> tsegismont : I've a presentation to give (in 15 minutes). So will be offline for 1h or 2.
[16:15:53] <chirino> k
[16:16:00] <chirino> peeking
[16:20:20] <gemmellr> rajith: purplefox: is the bridge stuff using a particular branch of core? I had a peek around the changes needed after the above PR, but it doesnt compile against the latest core snapshot pulled in
[16:20:50] <gemmellr> chirino: I edit the comment to note I also tweaked the benchmark bits
[16:21:40] <gemmellr> chirino: as it turns out, granting so much credit slows it down in certain cases, because it spends all its time sending and cant recieve..
[16:22:23] <chirino> good find
[16:30:08] <rajith> gemmellr: yea it's using flow_control branch
[16:30:27] <rajith> gemmellr: sorry I was getting some food
[16:34:19] <gemmellr> rajith: great thanks
[17:16:41] <gemmellr> rajith: purplefox: raised a PR with fixup for the earlier change: https://github.com/vert-x3/vertx-amqp-bridge/pull/7
[17:17:42] <rajith> gemmellr: thanks Robbie
[18:25:55] <kislo_metal> what is aproach of vertx's testing could be considered as best practice? With VertxJunitRunner or with bare TestSuite without junit? Thank you