Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1446764400 [2017/05/27 13:44] (current)
Line 1: Line 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