Differences

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

Link to this comparison view

— irc:1449788400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[10:08:52] *** ChanServ sets mode: +o temporalfox
 +
 +[10:14:15] <temporalfox> hi all
 +
 +[10:17:13] <temporalfox> we should start the release process today
 +
 +[10:17:37] <temporalfox> so we only accept last minute bug fixes / doc changes after review
 +
 +[10:29:32] <gigo1980> hi volks, does anyone has used dropwdown metrics ?
 +
 +[10:29:53] <gigo1980> i have a clustered vertx system. and i have a verticle that should manage the metric parts
 +
 +[10:30:50] <gigo1980> but how can i handle this. because the dropdown vertx service is already initialized by an other node in the serup
 +
 +[10:30:52] <gigo1980> setup
 +
 +[11:04:11] <cescoffier> what do you mean by "manager the metrics parts"
 +
 +[11:09:05] <tsegismont> cescoffier, hi
 +
 +[11:09:10] <cescoffier> Hi tsegismont
 +
 +[11:09:16] <tsegismont> mars01.host13.vertx.eventbus.36541247-8ae2-41b2-bd3f-fac9b19a8812.processingTime
 +
 +[11:09:21] <tsegismont> https://vertx.ci.cloudbees.com/view/vert.x-3/job/vert.x3-hawkular-metrics/43/consoleFull
 +
 +[11:09:40] <tsegismont> any idea where do these bus handlers come from ?
 +
 +[11:12:28] <cescoffier> tsegismont : no clue, @temporalfox ?
 +
 +[11:12:45] <temporalfox> which handlers ?
 +
 +[11:13:07] <temporalfox> what is "mars01.host13" ?
 +
 +[11:13:25] <cescoffier> I guest it's someone one of you has created....
 +
 +[11:13:31] <temporalfox> vertx uses internally event bus handlers for
 +
 +[11:13:34] <temporalfox> TCP sockets
 +
 +[11:13:53] <temporalfox> also now we do have extra handlers for back pressure
 +
 +[11:14:52] <temporalfox> but id is like UUID-credit
 +
 +[11:24:45] <tsegismont> temporalfox, 'mars01.host13' is the metric prefix used in hawkular-metrics module tests
 +
 +[11:24:54] <temporalfox> ok
 +
 +[11:25:01] <temporalfox> so which handlers are you seing ?
 +
 +[11:25:21] <tsegismont> temporalfox, if must be the TCP temporary handlers then
 +
 +[11:25:30] <temporalfox> if it's a UUID yes
 +
 +[11:25:40] <temporalfox> at some point I wnated to prefix them with
 +
 +[11:25:43] <temporalfox> "vertx."
 +
 +[11:25:45] <tsegismont> because they appear in the TCP related tests only
 +
 +[11:25:50] <temporalfox> so the SPI could ignore them
 +
 +[11:25:57] <temporalfox> or at least make a distinction
 +
 +[11:26:25] <tsegismont> +1
 +
 +[11:26:29] <tsegismont> we need a new issue :)
 +
 +[11:26:42] <tsegismont> temporalfox, so it's only TCP related
 +
 +[11:26:47] <tsegismont> not HTTP?
 +
 +[11:27:14] <temporalfox> https://github.com/eclipse/vert.x/issues/1240
 +
 +[11:27:21] <temporalfox> it is also for HTTP I think
 +
 +[11:27:23] <temporalfox> not sure
 +
 +[11:28:08] <temporalfox> it is for websockets
 +
 +[11:28:25] <temporalfox> there are two per websocket
 +
 +[11:28:33] <temporalfox>     Handler<Message<Buffer>> binaryHandler = msg -> writeBinaryFrameInternal(msg.body());
 +
 +[11:28:33] <temporalfox>     binaryHandlerRegistration = vertx.eventBus().<Buffer>localConsumer(binaryHandlerID).handler(binaryHandler);
 +
 +[11:28:34] <temporalfox>     Handler<Message<String>> textHandler = msg -> writeTextFrameInternal(msg.body());
 +
 +[11:28:35] <temporalfox>     textHandlerRegistration = vertx.eventBus().<String>localConsumer(textHandlerID).handler(textHandler);
 +
 +[11:28:55] <temporalfox> the idea is that you can use this ID to send a message
 +
 +[11:29:02] <temporalfox> to send somethign to a ws
 +
 +[11:29:08] <temporalfox> wondering if ppl really use this feature or not :-)
 +
 +[11:29:20] <temporalfox> I wanted to do something similar
 +
 +[11:29:30] <temporalfox> for Vert.x SHell TTY :-)
 +
 +[11:29:41] <temporalfox> so someone can broadcast text to shell sessions
 +
 +[11:30:54] <tsegismont> ok
 +
 +[11:32:12] <tsegismont> cescoffier, build fixed \o/
 +
 +[11:32:17] <tsegismont> https://vertx.ci.cloudbees.com/view/vert.x-3/job/vert.x3-hawkular-metrics/45/console
 +
 +[11:32:29] <cescoffier> tsegismont : amazing !
 +
 +[11:32:39] <cescoffier> tsegismont what was the reason ?
 +
 +[11:32:52] <tsegismont> i'll update the issue to explain why
 +
 +[11:33:06] <tsegismont> There's still a problem with the build trigger though
 +
 +[11:33:28] <tsegismont> The build runs only after a manual trigger or after vertx core is built
 +
 +[11:33:38] <tsegismont> I checked the build config
 +
 +[11:33:58] <tsegismont> "Build when a change is pushed to GitHub" is checked
 +
 +[11:34:20] <tsegismont> So maybe there's a webhook setup which is missing on the GH side
 +
 +[11:34:22] <tsegismont> I can't check
 +
 +[11:34:50] <tsegismont> I don't have access to the GH project settings
 +
 +[11:36:35] <temporalfox> ah yes we need to add webhooks
 +
 +[11:38:30] <temporalfox> acutally I don't have access to settings myself :-)
 +
 +[11:44:49] <tsegismont> temporalfox, that sounds like a mission for Superman - looking at you cescoffier ;)
 +
 +[11:51:43] <tsegismont> temporalfox, cescoffier I believe we're good for 3.2 release, is there anything I should/could do to help?
 +
 +[11:52:58] <cescoffier> tsegismont : no everything fine ! Thanks !
 +
 +[13:10:29] *** ChanServ sets mode: +o temporalfox
 +
 +[14:02:49] *** ChanServ sets mode: +o temporalfox
 +
 +[21:23:06] <Sam__> I am trying to run the one of the existing test cases in HttpTest.testSendRangeFileFromClasspath and it fails with "Connection reset by peer" error
 +
 +[21:23:37] <Sam__> am i missing something?
 +
 +[21:25:28] <Sam__> nm. It runs fine on the master.