Differences

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

Link to this comparison view

irc:1451948400 [2017/05/27 13:44] (current)
Line 1: Line 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>​ http://​vertx.io/​docs/​vertx-core/​java/​ 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: https://​github.com/​vert-x3/​vertx-redis-client/​blob/​master/​src/​test/​java/​io/​vertx/​test/​redis/​PubSubTest.java#​L59
 +
 +[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 http://​vertx.io/​docs/​apidocs/​io/​vertx/​core/​http/​WebsocketVersion.html
 +
 +[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, https://​github.com/​vert-x3/​vertx-mail-client/​tree/​issue48_hostnamenotasync
 +
 +[20:31:37] <​purplefox>​ also it's a more general issue
 +
 +[20:31:38] <​purplefox>​ https://​github.com/​eclipse/​vert.x/​pull/​1107
 +
 +[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:​ https://​github.com/​vert-x3/​vertx-mail-client/​pull/​50
 +
 +[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