[09:12:06] <bcd> is it possible to call ObservableHandler.toBlocking() in a worker thread? For instance ObservableHandler.toBlocking.first() never returns, but when i subscribe to the ObservableHandler the first onNext gets called within a second.

[12:05:25] <gokl> Hi, i have trouble getting metrics to work in vert.x 3.0.0. I run a verticle using the io.vertx.core.Starter with -conf pointing to my config file ( http://pastebin.com/vDdNaU3h ). Im using vertx web and setup this handler for a route http://pastebin.com/dC57Evex . When the handler gets executed the metrics object is null. Why?

[13:10:04] <temporal_> gokl you need to configure the metrics via the system properties

[13:10:40] <temporal_> using -Dvertx.metrics.options.enabled=true

[13:10:41] <temporal_> etc…

[13:20:24] <gokl> temporal_: Thank you. Does this apply for the VertexOptions, too? Are they configurable via the -conf file?

[13:20:43] <temporal_> so there are a few options you can configure this way

[13:20:47] <temporal_> it's not really documented I think

[13:21:07] <temporal_> vertx.options.

[13:21:09] <temporal_> vertx.deployment.options.

[13:21:14] <temporal_> vertx.metrics.options.

[13:21:25] <gokl> oh, nice. Where did you get these names?

[13:21:31] <temporal_> look at the Starter class

[13:21:38] <temporal_> io.vertx.core.Starter

[13:21:48] <temporal_> for instance

[13:21:49] <temporal_> public static final String VERTX_OPTIONS_PROP_PREFIX = “vertx.options.”;

[13:21:57] <gokl> Thx

[13:22:12] <temporal_> I think cl[unknown:eacute]ment is going to work on Starter improvements soon

[13:22:14] <temporal_> so hopefully that will get better

[14:44:07] <purplefox_> temporal_: did you have a chance to ping thomas segismont about maintaining the hawkular component?

[14:44:20] <temporal_> not yet, I think he is in holidays

[14:44:26] <temporal_> I will send him an email

[14:51:45] <cescoffier> purplefox_ temporal_ pmlopes : I've created “high-level/umbrella” issues for the 3.1

[14:52:03] <cescoffier> for core issues, you have them in the issues repository with the link to the lovely BZ

[14:52:13] <cescoffier> (the BZ issue also reference the GH issue)

[14:52:52] <purplefox_> cescoffier: great. i think we should also assign these issues to the relevant component maintainer

[14:53:21] <purplefox_> they should all be in the “committers” team

[14:53:29] * ChanServ sets mode: +o temporalfox [14:53:57] <purplefox_> btw.. on a related note, i am doing some housekeeping with the GitHub teams, getting rid of unneeded ones. [14:54:14] <cescoffier> purplefox_: that was the next step [14:54:14] <purplefox_> i noticed a few teams with just you in them: [14:54:31] <cescoffier> purplefox_: just me ? [14:54:32] <purplefox_> vertx-hazelcast, mongo-commmitters, vertx-sql-common [14:54:40] <purplefox_> https://github.com/orgs/vert-x3/teams [14:54:48] <purplefox_> do you need these? [14:54:55] <cescoffier> ah ah ah …. [14:54:58] <cescoffier> nope [14:55:17] <cescoffier> but I need the commitership on the related repositories [14:55:25] <cescoffier> temporalfox added me to these teams to let me push stuff on the repositories [14:55:41] <purplefox_> i think now it should be simpler - you are in the committers team [14:55:49] <purplefox_> so we can just add that to the repository [14:55:55] <purplefox_> if it's not already added [14:56:19] <purplefox_> so basically any official committer has read/write access to any official repo [14:56:36] <purplefox_> official committer being anyone who maintains one or more official components [14:56:59] <purplefox_> ok, i'll delete these other teams [15:00:10] <cescoffier> could you add jstrachan to the commiters ? Need it to assign him the DNS discovery issue [15:00:28] <jstrachan> coolio [15:00:56] <purplefox_> jstrachan: i sent you an invite :) could you accept? [15:01:31] <jstrachan> have done [15:02:07] <purplefox_> thanks [15:02:11] <purplefox_> cescoffier: ^ [15:02:27] <cescoffier> ok [15:20:30] <purplefox_> temporalfox: k thx [15:58:15] <bcd> is it possible to call ObservableHandler.toBlocking() in a worker thread? When I try it ObservableHandler.toBlocking.first() never returns, but when i subscribe to the ObservableHandler the first onNext gets called within a second. [16:38:05] <temporalfox> purplefox_ hi [16:39:28] <temporalfox> bcd could you provide a reproducer for this case ? [16:42:33] <bcd> temporalfox: yeah np, i'll have time tomorrow to write one and will post an url to the code here [16:42:42] <temporalfox> bcd thanks [16:42:52] <bcd> yw [17:36:49] <rajith> purplefox_: hey Tim, heard you were looking for me [18:08:52] <jac0> Client clicks a widget, which starts a timer on the server pumping some realtime data at x interval over an clientuuid eventbus. Client disconnects/browser crashes. How to cleanup? Is the number of subscribers to an eventbus exposed to a verticle perhaps? [19:36:40] <dw33zil> I need to fire off a set of work, and wait for them all to complete (or fail). I need some sort of count down latch, or completion handler, and was wondering if one existed. [19:37:02] <dw33zil> Also happy to hear why this is a good or bad idea.. i'm about 10hours into vert.x. so assume I know very litte. [19:38:08] <zerkz> How can I return a result of a vertx JDBCClient async SQL query inside of a method? [19:38:20] <zerkz> do I need to wrap it with some sort of AsyncResult/handler? [21:40:24] * ChanServ sets mode: +o purplefox_