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

[00:28:21] * ChanServ sets mode: +o temporal_ [01:31:04] <Diegote> Hi everyone! Do you know of any open source project using Vert.x? I would like to see some real life code; in particular how is a fairly complex problem divided into verticles. [08:54:35] * ChanServ sets mode: +o temporalfox

[09:58:24] <rbt> <clement> Hi Diegote, you can have a look at

[10:27:18] <Zwergal> Hi, has anyone of you tried to start a vertx fatjar on freebsd? I try to write a init.d script with the freebsd stuff and I'm not able to get the pid of the vertx process[unknown:hellip]

[10:28:54] <rbt> <clement> Hi, I never used freebsd but did you use the init.d from the vert.x blog ?

[10:29:33] <rbt> <clement> another solution is to use [unknown:ldquo]start[unknown:rdquo] and [unknown:ldquo]stop[unknown:rdquo] : java -jar your-fat-jar start -id=my-app and java -jar your-fat-jar stop my-app

[10:30:29] <Zwergal> No, i tried writing my own because on freebsd you have some helper functions which you can use

[10:31:12] <rbt> <clement> with the [unknown:ldquo]start[unknown:rdquo] and [unknown:ldquo]stop[unknown:rdquo] you don[unknown:rsquo]t need a PID, as it looks into the list of processus to find it

[10:31:23] <Zwergal> Ok, I will try this

[17:28:40] <melvinross_> SockJS disconnects, but it gets a custom reason 3000: “Go Away!!”

[17:52:44] <saltuk> can some1 help on this ?

[17:53:54] <temporalfox> melvinross sorry as away

[17:54:23] <temporalfox> Go Away ?

[17:59:03] <melvinross> hey sorry tim

[17:59:10] <melvinross> it's actually the default message

[18:00:37] <temporalfox> it's julien :-)

[18:01:04] <temporalfox> give us a reproducer and we will have a look at it

[18:02:40] <melvinross> cool

[18:02:49] <melvinross> congrats on becoming lead

[18:03:42] <temporalfox> thanks !

[18:04:10] <temporalfox> saltuk you case seem very complex to look at :-)

[18:04:16] <temporalfox> and now my brain is kind of fried

[18:04:28] <temporalfox> I will have a look later

[18:04:35] <temporalfox> can you send a mail on vertx google group ?

[18:04:40] <temporalfox> so other persons may have a look too

[18:07:27] <saltuk> temporalfox ok ..

[18:07:37] <temporalfox> thanks

[18:07:49] <saltuk> ;)

[18:18:40] <tsegismont> temporalfox, hi, when you have nested option classes, annotated with @DataObject(generateConverter = true)

[18:18:50] <temporalfox> yes

[18:18:53] <temporalfox> hi tsegismont

[18:19:16] <tsegismont> is it expected that the converter #toJson method doesn't look at nested option object?

[18:20:03] <temporalfox> no it must be a bug

[18:21:40] <temporalfox> pehraps now you can use toJson

[18:21:45] <temporalfox> and add yourself the nested stuff

[18:21:47] <temporalfox> and file a bug

[18:44:32] <tsegismont> temporalfox, actually it might not be a bug, how would codegen know how to transform a dataobject to jsonObject? For jsonObject→dataObject, there's the constructor. But there is no standard toJson method

[18:45:26] <temporalfox> yep

[18:45:36] <temporalfox> but when it makes the metamodel at compilation time

[18:45:45] <temporalfox> it find if it has toJSon() method or not

[18:45:51] <temporalfox> (without hte need for an interface impl)

[18:46:20] <temporalfox>

[18:46:23] <temporalfox> jsonifiable

[18:46:38] <temporalfox> so the toJson() template could use this jsonifiable

[18:46:45] <temporalfox> and use it

[18:46:54] <temporalfox> vars.put(“jsonifiable”, jsonifiable);

[18:48:04] <temporalfox> it should work I think

[18:48:11] <temporalfox>

[18:51:36] <tsegismont> temporalfox, ok, here's the issue:

[18:53:29] <tsegismont> temporalfox, Now logging off to start a fire in the fireplace - Mandagout is cold ;)

[18:53:47] <tsegismont> See you later

[18:55:44] <temporalfox> :-)

[20:19:59] <melvinross> julien, can I ask you a question about socks eventbusbridge? Why does the server listen for pings and disconnect after 10 seconds?

[20:20:20] <melvinross> server → client heartbeats are implemented

[20:20:40] <melvinross> and the clients should return “[]” according to the sockjs spec

[21:20:21] <temporalfox> melvinross quite strange indeed

[21:20:40] <temporalfox> can you set a break point in the socket close ?

[21:20:43] <temporalfox> to see why it is called

[21:21:57] <melvinross> client or server side?

[21:22:40] <temporalfox> server

[21:22:40] <temporalfox> but well

[21:22:47] <temporalfox> do you know who disconnects ?

[21:22:53] <temporalfox> can you run wireshark ?

[21:24:35] <temporalfox> I think also your browser can have neat tool to understand what is going on

[21:24:40] <temporalfox> but it depends on your browser

[21:24:47] <temporalfox> and I'm not much familiar

[21:35:04] <melvinross> So the thing that lead me to this discovery at all, was sending messages formatted in the SockJS bridge format

[21:35:15] <melvinross> from a normal sockJS connection

[21:35:26] <melvinross> not utilizing vertx-eventbus.js

[21:35:50] <melvinross> if i manually implement the 5 second {type:“ping”} messages

[21:36:00] <melvinross> the connection isn't quickly killed

[21:36:43] <melvinross> and reading the vertx-web socks code, vertx kills the connection if hasn't gotten a ping in the default time out interval

[21:42:25] <temporalfox> on the client you must send ping messages

[21:42:26] <temporalfox> yes

[21:42:34] <temporalfox> what is your client ?

[21:42:43] <temporalfox> vertx-eventbus.js should do that for you

[21:45:07] <melvinross> yes it does

[21:45:34] <melvinross> my question was, why? if the server is sending “h” heartbeat frames?

[21:46:04] <temporalfox> why what ?

[21:46:10] <temporalfox> is there a bug on client ?

[21:46:15] <temporalfox> does it send pings ?

[21:46:31] <temporalfox> ah

[21:46:31] <temporalfox> ok

[21:46:40] <temporalfox> you are using a normal sockJS connection

[21:46:48] <temporalfox> yes you need to do that yourself then

[21:46:59] <melvinross> i understand that if i send the ping it stays open

[21:47:25] <melvinross> what i'm saying is that, after looking through the vertx sockjs implementation, it appears that the “h” frame is sent after the “o” frame

[21:47:30] <melvinross> whether you're using it bridged or not

[21:47:47] <melvinross> and those “h” frames are sent to the client continuously as a heartbeat

[21:48:14] <melvinross> the sockjs protocol defines that clients can respond to those heartbeats with an “[]” frame

[21:49:07] <melvinross> except, the info URL that's generated by vertx doesn't specify “server_heartbeat_interval”

[21:49:25] <melvinross> which would trigger sockJS clients to respond to the heartbeat frames

[21:49:40] <temporalfox> I'm not familliar with sockjs actually

[21:49:46] <temporalfox> I am more with websockets

[21:50:10] <melvinross> in short, I'm saying that the current implementation is almost double heartbeating

[21:51:32] <temporalfox> ahhh

[21:51:35] <temporalfox> for which protocol ?

[21:51:49] <temporalfox> I mean underlying protocol chosen by sockjs

[21:51:53] <temporalfox> websocket ?

[21:53:46] <melvinross> the heartbeat frame is sent from SockJSSession, so I would assume all of them

[21:53:52] <melvinross> since they all get a reference to SockJSSession

[21:54:29] <melvinross>

[21:55:33] <temporalfox> that is an hearbeat from the server

[21:56:28] <melvinross> yes and if we set “server_heartbeat_interval” in the /info URL we'd get a response back from the clients

[21:58:11] <melvinross> we basically have sockjs heartbeats AND vertx heartbeats via the ping in vertx-eventbus.js

[21:59:40] <temporalfox> vertx heartbeats are initiated by the client right ?

[22:00:20] <temporalfox> I think that it is not a problem to have 2 pings

[22:00:28] <temporalfox> meaning that they are not in the same direction

[22:00:40] <temporalfox> and it's not the same protocol really

[22:01:15] <melvinross> that's true. it's two pings in the case of a bridge

[22:01:21] <melvinross> it's only*

[22:02:18] <melvinross> the reason I was using a raw sockJS connection is

[22:02:37] <melvinross> 1. is I was contemplating building more clients for the SockJS bridge to add other languages

[22:02:57] <temporalfox> and there is also an hearbeat in websocket itself :-)

[22:03:26] <melvinross> 2. Testing out how much overhead there would be exposing the event bus bridge to clients without telling them what it is

[22:03:34] <temporalfox> if you are building other client, you may want to try also the TCP bridge

[22:03:43] <temporalfox> if your client can use sockets

[22:03:59] <melvinross> i.e simply give them the spec of how messages should be formatted

[22:04:24] <melvinross> and not explicitly telling them that they're bridging the event bus

[22:05:35] <melvinross> which seems silly, but it's to stifle silly philosophical debates internally

[22:05:41] <melvinross> and by seems silly, i mean it is silly

[22:06:14] <melvinross> bridging in with raw SockJS was super simple, i just kept getting disconnected and realized the ping was why

[22:06:47] <temporalfox> what do you mean by internally for your debate ?

[22:08:04] <melvinross> just FUD. people not wanting to explicitly rely on event bus bridge client

[22:08:25] <melvinross> but being willing to send JSON formatted to the bridge spec

[22:08:41] <melvinross> like i said, silly stuff

[22:09:54] <melvinross> and on the journey, i noticed the dual heartbeats and was wondering if there was a reason to have both

[22:10:24] <temporalfox> honnestly I don't know sockjs much

[22:10:35] <temporalfox> I know the principles

[22:10:44] <temporalfox> and how you can connect with a websocket

[22:21:45] <melvinross> i understand that

[22:21:53] <melvinross> it just strange

[22:25:22] <melvinross> since internally in vertx, it's disconnecting if either is missed. I'm still actually not convinced that the WebSocket module is behaving correctly, but i haven't had time to check it

[22:25:56] <melvinross> i'm probably going to this weekend, because i think

[22:26:01] <melvinross> may be affected by it

[22:31:06] <temporalfox> ok

[22:31:14] <temporalfox> if you can exhibit a but

[22:31:16] <temporalfox> bug

[22:31:25] <temporalfox> it would be very nice

[22:31:30] <temporalfox> if you can fix it, even nicer :-)

[22:31:48] <melvinross> if i nail it down, i'll submit a PR

[22:36:16] <temporalfox> good luck sherlock

[23:00:37] <jtruelove_> looking at the DnsClientImpl code to deal with the blocking DNS lookup what exactly is looking to be changed? I see the .getHostAddress() call in the lookup routine is the crux of the issue? Or are you looking to do something different than even using the DnsQuery with questions code in general? as that uses the channel setup with future listeners etc..

[23:01:41] <jtruelove_> temporalfox ^ - I haven't found a ton of docs yet on netty 4.1 dns async support other than the sdk api info

[23:02:12] <temporalfox> jtruelove_ it's the same for http2 doc :-)

[23:02:22] <temporalfox> my advice : look at Netty 2 source examples

[23:02:49] <temporalfox> what is the package name of the async dns ?

[23:03:09] <temporalfox> codec-dns ?

[23:04:01] <temporalfox> Package io.netty.resolver.dns

[23:04:05] <jtruelove_> hehe i saw norman's name in the header on a lot of the classes but that was about it

[23:04:10] <temporalfox> I think this is what we are looking for

[23:04:21] <temporalfox> DnsNameResolver

[23:04:32] <temporalfox> DefaultDnsCache

[23:04:32] <jtruelove_> k i can take a look starting there

[23:04:32] <temporalfox> so I think we should use that somehow

[23:04:55] <jtruelove_> the .getHostAddress is certainly blocking being java's thing

[23:04:55] <temporalfox> so it is in resolver-dns

[23:04:58] <temporalfox> yes

[23:05:09] <temporalfox> such lookup should be replaced by resolver-dns

[23:05:17] <temporalfox> and also we should use a cache :-)

[23:05:21] <jtruelove_> i wasn't sure if the channel pipeline listening was being treated as async or not

[23:05:27] <temporalfox> and of course it should be configurable :-)

[23:05:37] <jtruelove_> a timed cache or a process lifetime cache

[23:05:57] <jtruelove_> aka would you ever re-resolve a dns entry

[23:06:05] <temporalfox> I think it should use

[23:06:05] <temporalfox> public final Future<T> resolve(String inetHost)

[23:06:09] <temporalfox> and the Future when resolved

[23:06:12] <temporalfox> would continue the flow

[23:06:31] <temporalfox> there is an existing cache in resolver-dns

[23:06:35] <jtruelove_> so to start with the goal is to just get rid of that core java blocking call

[23:06:57] <temporalfox> yes that's the idea

[23:07:02] <temporalfox> this is hurting us

[23:07:10] <jtruelove_> cool cool, yeah i've experienced it

[23:07:32] <jtruelove_> this code is slightly complex to jump right in to

[23:07:44] <jtruelove_> given the lack of docs and things but i'll continue on

[23:07:45] <AlexLehm> jtruelove_: resolving a dns entry again is necessary in some cases, e.g. if a server is running for a long time the dns entries can change

[23:07:58] <jtruelove_> yeah that was my point more or less

[23:08:03] <temporalfox> we need to look at the cache config

[23:08:30] <AlexLehm> i.e. it should honour the ttl settings if possible

[23:08:30] <temporalfox> and provide configurability

[23:08:30] <temporalfox> perhaps we could wrap this

[23:08:31] <jtruelove_> so you intentionally want it to re-resolve

[23:08:31] <temporalfox> as a vertx DnsResolver

[23:08:33] <temporalfox> that would be available from Vertx directly

[23:08:40] <temporalfox> vertx.dnsResolver()

[23:08:49] <temporalfox> so it could be easily reusable

[23:09:50] <temporalfox> the DefaultDnsCache provides TTL config

[23:10:01] <temporalfox> anyway just start with something small

[23:10:34] <temporalfox> with tests

[23:10:34] <jtruelove_> yeah for sure that is my plan, i don't trust myself with this code

[23:10:41] <temporalfox> AlexLehm you need to resolve yourself DNS ? or you can let the NetClient do it ?

[23:11:09] <temporalfox> I think one first approach would be to expose this netty DnsResolver in VertxInternal

[23:11:13] <temporalfox> as is

[23:11:16] <jtruelove_> i ran into issues with netclient and having to ressolve the dns to an ip before

[23:11:22] <temporalfox> and later we can wrap it with a proper api

[23:11:28] <temporalfox> if we need to expose it

[23:11:51] <temporalfox> I think the net client should resolve this automatically as it does today

[23:11:54] <AlexLehm> clement implemented it for netclient, as soon as that is doing inside the netclient, we can remove that again

[23:12:09] <temporalfox> AlexLehm ok

[23:12:16] <temporalfox> so you would not need that to be exposed

[23:12:23] <AlexLehm> yes

[23:12:27] <temporalfox> ok then

[23:12:35] <temporalfox> no need to mak this more complex than it is

[23:13:06] <temporalfox> jtruelove_ I think one way to do it taht is simple is to expose a “resolve” method in VertxInternal

[23:13:18] <jtruelove_> with a callback

[23:13:21] <temporalfox> yes

[23:14:16] <jtruelove_> seems clean

[23:14:50] <jtruelove_> i'll see where i make it with the netty code, i haven't been in that source much

[23:16:05] <temporalfox> there are tests in resolver-dns

[23:16:27] <temporalfox>

[23:17:09] <temporalfox> pretty straightforward

[23:17:11] <temporalfox> DnsNameResolver resolver = newResolver().build();

[23:17:18] <temporalfox> resolver.resolve(“”).

[23:17:22] <temporalfox> then you get a Promise

[23:17:29] <temporalfox> this promise would trigger the callback

[23:18:13] <jtruelove_> right, that's a great starting point

[23:18:16] <temporalfox> btw I'm still using Netty 4.1.0.CR1 because CR2 has a blocking bug in http2

[23:20:05] <jtruelove_> ah i checked out the http2 branch

[23:22:13] <temporalfox> you should check it out

[23:22:21] <temporalfox> but get an early commit

[23:22:48] <temporalfox>

[23:22:49] <temporalfox> this one

[23:22:58] <temporalfox> so you don't have all http2 commits

[23:23:21] <jtruelove_> kk will do