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

[04:45:22] * ChanServ sets mode: +o temporal_ [11:37:50] * ChanServ sets mode: +o temporalfox

[11:56:44] * ChanServ sets mode: +o temporal_ [12:48:06] * ChanServ sets mode: +o temporalfox

[13:19:20] <mcw> hi everybody, I'm not really sure whether java 8 is required for vert.x 3 or not? can someone please confirm?

[13:25:38] <sunnyawake> hi, does redis psubscribe work in 3.2?

[13:28:53] <mcw> hi everybody, I'm not really sure whether java 8 is required for vert.x 3 or not? can someone please confirm?

[13:29:04] <millrossjez> @mcw yes I'm pretty sure it is

[13:29:36] <millrossjez> says it is

[13:29:40] <millrossjez> “Also make sure you have a Java 8 JDK on your PATH.”

[13:30:27] <millrossjez> @sunnyawake, sorry no idea

[13:48:04] <cescoffier> mcw : yes java 8 is required. It won't run without a Java 8 JVM

[13:48:38] <mcw> ok, thank you!

[13:48:40] <cescoffier> sunnyawake : yes psubscribe should work in 3.2

[13:55:15] <sunnyawake> i opened two redis-cli and a vertx redis client, redis client failed to receive message

[13:57:17] <sunnyawake> i tried lettuce, it works as expected

[14:04:57] <pmlopes> @sunnyawake psubscribe works and there are tests showing it, maybe they are a good start for you:

[14:29:47] * ChanServ sets mode: +o purplefox [14:32:41] <sascha_> Hi all, currently I'm implementing Vert.x Metrics SPI for Amazon CloudWatch, do you know where I can find the definition of the standard metric types that are sent over the EventBus? [14:37:24] <sascha_> Nevermind, got it [19:45:49] <andrew_> Can anybody tell me which RFC draft vert.x websockets implement or support? [20:00:09] <temporalfox> andrew_ I don't know about RFC, however when you configure the websocket client/server you can chose different version of the protocol [20:00:42] <temporalfox> look at [20:11:53] <andrew_> Is that available for the server? I don't see that option anywhere. Thanks for the help. [20:15:06] <andrew_> I'm assuming it would have been specified in the HttpServerOptions obj when I call vertx.createHttpServer() [20:25:29] <AlexLehm> temporalfox: Julien can I ask you something about mocking? [20:25:36] <temporalfox> sure [20:26:23] <AlexLehm> I have fixed a non-async issue in vertx-mail and I assume I could test that with Powermock, but that is kind of complicated, would you consider it ok to not implement a test for that [20:26:42] <temporalfox> andrew_ it is available, as we do test the vertx http client with vertx http server :-) [20:27:12] <temporalfox> AlexLehm I'm not a fan of mocking, unless it's really necessary [20:27:25] <temporalfox> I rarely used mocking (like a couple of times) [20:27:33] <temporalfox> that's my personal opinion :-) [20:27:50] <temporalfox> what do you mean by “non-async issue” ? [20:28:25] <AlexLehm> the client got stuck on the event loop when the dns request took longer [20:28:37] <AlexLehm> blocking issue i should say [20:29:03] <temporalfox> do you have something like a branch with a commit diff so I can have a quick look ? [20:29:49] <temporalfox> you are using execute blocking ? [20:29:57] <purplefox> AlexLehm: dns blocking is a known issue, i believe there is an issue for this already [20:30:48] <AlexLehm> ah, the issue was mine so to speak since I used InetAddr directly, I have changed that by putting it into a executeBlocking block before starting the client [20:31:25] <AlexLehm> temporalfox: yes, [20:31:37] <purplefox> also it's a more general issue [20:31:38] <purplefox> [20:31:47] <purplefox> this can be fixed in netty 4.1.0 [20:31:55] <purplefox> which will provide async dns [20:32:00] <purplefox> or you can use the vert.x async dns [20:33:22] <AlexLehm> i have used InetAddress getCanonicalHostName, not sure what that acually does internally, i figured that this doesn't use DNS, but it turned out it does sometimes [20:33:43] <purplefox> yes, all JDK dns lookups are blocking [20:34:04] <purplefox> sometimes it just reads hosts file i think but other times it has to issue a real dns lookup to a remote server [20:34:15] <purplefox> but that's all implementation dependent [20:34:37] <purplefox> executeblocking is a reasonable workaround [20:34:42] <AlexLehm> i think i have fixed the isue with the hostname at least in any case [20:35:33] <temporalfox> AlexLehm btw we would like to make a 3.2.1 release this month, so this could be fixed in this release [20:36:11] <AlexLehm> it is more or less finished, if we don't need a unit test [20:36:27] <AlexLehm> if we decide we don't need one [20:53:28] <AlexLehm> temporalfox: [20:56:10] <AlexLehm> if you could review it please [23:30:42] * ChanServ sets mode: +o temporal_

[23:33:17] <sunnyawake> how can i detect client websocket disconnect using ping?

[23:39:54] <sunnyawake> what happens if eb.send to an alreay gone-away client?

[23:42:43] <sunnyawake> ok, i got eb.send with DeliveryOptions