[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