This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[01:05:19] <DP_2014> I think there is a bug in io.vertx.ext.web.impl.Locale

[01:06:50] <DP_2014> static default Locale create(String language, String country) { return new LocaleImpl(language, country, (String)null); } ###### (String)null sets the variant to null value, which when it gets converted to java.util.Locale throws an Exception as variant cannot be null.

[09:15:19] * ChanServ sets mode: +o purplefox [12:45:17] * ChanServ sets mode: +o temporalfox

[14:44:20] * ChanServ sets mode: +o temporalfox [14:57:45] <tsegismont> Hi everyone [14:58:15] <tsegismont> I'm working on NetClient and HttpClient metrics support in vertx-monitor [14:58:34] <tsegismont> There's one thing which is a bit annoying [14:59:34] <tsegismont> When you create a client connection with, for example, [14:59:51] <tsegismont> in the io.vertx.ext.hawkular.impl.NetClientMetricsImpl#connected callback [15:00:24] <tsegismont> you don't get a remoteAddress parameter with, but the actual IP [15:01:22] <tsegismont> So it seems difficult, if not impossible, to implement host-based filtering [15:01:54] <tsegismont> For example: I want to configure vertx-monitor to send metrics for TCP connections to only [15:02:01] <tsegismont> Should I open an issue? [16:15:49] * ChanServ sets mode: +o temporalfox

[16:19:12] <tsegismont> temporalfox, hi, have you seen the comments above?

[16:19:21] <temporalfox> nope, I was away

[16:19:25] <temporalfox> ah

[16:19:27] <temporalfox> actually yes

[16:19:31] <temporalfox> at 3pm ?

[16:19:34] <tsegismont> yep

[16:19:52] <temporalfox> there is a DNS client you can use

[16:21:44] <tsegismont> temporalfox, that wouldn't work

[16:21:55] <tsegismont> if you connect to

[16:22:05] <tsegismont> it will be resolved to an IP

[16:22:13] <tsegismont> but then if you lookup this IP

[16:22:27] <tsegismont> you will get something like

[16:22:36] <tsegismont> doesn't match

[16:23:19] <temporalfox> so you want this info in the net socket metrics client callback ?

[16:23:45] <tsegismont> yes, so that in metrics config object

[16:23:53] <tsegismont> the user can say

[16:24:18] <temporalfox> so it's a metrics issue and not really a netsocket client issue right ?

[16:24:34] <tsegismont> “I want to monitor http client connections to”

[16:24:49] <tsegismont> temporalfox, yes and no

[16:24:50] <tsegismont> :)

[16:25:10] <temporalfox> perhaps that the client could resolve the name of

[16:25:12] <tsegismont> The Metrics API gives you a remote address (SocketAddress)

[16:25:17] <temporalfox> and filter according to the IP

[16:25:25] <temporalfox> I mean the metrics spi impl

[16:25:33] <temporalfox> just a thought

[16:25:33] <tsegismont> but it does so querying the netty channel

[16:25:45] <tsegismont> instead of the parameters which were used to create the connection

[16:25:54] <temporalfox> please open an issue anyway and we'll figure out

[16:26:07] <temporalfox> in the vert-x3/issues or in bugzilla eclipse

[16:26:26] <tsegismont> see

[16:26:43] <tsegismont> sock.setMetric(metrics.connected(sock.remoteAddress()));

[16:27:11] <tsegismont>

[16:30:13] <tsegismont> temporalfox, will do

[17:01:59] <stampy88> hi all. I was hoping that someone would have a chance to review this PR

[17:02:19] <stampy88> I originally submitted it a month ago, but re-submitted last night because the IP Validation was not passing

[20:24:43] <Kioz> Hi

[20:56:47] <stampy88> pmlopes: if you have time, can you take a look at this PR?

[20:58:22] <stampy88> this is a painful to code around now with try..catches