[00:13:34] <voidDotClass> hey guys, is that web sockets bug fixed?
[00:13:49] <voidDotClass> where websocket connections were not being closed / timed out
[00:18:06] <voidDotClass> temporal_, purplefox_ ?
[00:18:30] <purplefox_> voidDotClass: do you have a link the bug report?
[00:19:47] <voidDotClass> purplefox_, not sure if i made a bug report or not, but i showed you this test a while back which shows the issue, https://gist.github.com/aliakhtar/602ee81f58046cdcfb9b
[00:19:57] <voidDotClass> it fails, the connection is never timed out
[00:20:13] <purplefox_> voidDotClass: ok, can you add a bug report with a reproducer then it will get investigated :)
[00:20:28] <voidDotClass> purplefox_, where should i send the bug report?
[00:20:32] <voidDotClass> or add it
[00:21:50] <purplefox_> officially you should add a bug report in Eclipse bugzilla but that's a pita, so how about just posting something on the google group with a link to the reproducer and I will take a look over the weekend :)
[00:22:47] <voidDotClass> sure, or a github issue on https://github.com/eclipse/vert.x ?
[01:08:25] <purplefox_> voidDotClass: ok i tried your example, and it does time out for me as expected… but the thing to bear in mind is the argument to idleTimeout is in seconds, not ms, so it takes 100seconds (= 1 minute 40 seconds) to timeout
[01:09:26] <purplefox_> if you reduce the timeout to, say, 5, you will see it timeout more quickly
[01:09:47] <voidDotClass> purplefox_, i see, i'll try in m5, may be it has been fixed. another thing i noticed was, if you establish a websocket conn, then close the browser prematurely (e.g by powering off the phone), then the server never closed the websocket conn (or timed out)
[01:10:25] <purplefox_> voidDotClass: this is just the way tcp works
[01:10:53] <voidDotClass> purplefox_, but i thought a timeout was built in to time it out in such a case?
[01:11:14] <purplefox_> if you have a tcp connection between a client and a server, and pull out the cable (or shutdown the device), in the eyes of the server the connection is still alive, as TCP is a reliable protocol
[01:11:38] <purplefox_> and you can actually plugin in the connection after a few seconds and it will start working again
[01:11:47] <purplefox_> the miracles of tcp
[01:11:55] <purplefox_> yes there is a timeout built in
[01:12:04] <purplefox_> but by default it is very long (2 hours i think?)
[01:12:21] <voidDotClass> purplefox_, i see, is there a way to shorten this timeout?
[01:13:27] <purplefox_> yep one sec. but the way most applications deal with this problem is to send pings on the connection
[01:13:42] <purplefox_> and if they don't receive a pong they assume the connection is gone and close it
[01:13:55] <voidDotClass> purplefox_, yeah bit that'd require building my own timeout / conn pool
[01:14:07] <purplefox_> websockets have ping/pong build in
[01:14:15] <voidDotClass> if there's a way built in to vertx/netty to timeout after X idle time, i'd rather do it
[01:14:40] <purplefox_> just we have idle timeout too, as above
[01:15:37] <purplefox_> take a look at httptest#testServerWebsocketIdleTimeout - this tests the timeout - as mentioned before the problem with your test is that it was setting timeout to 100 seconds so you probably weren't noticing it
[01:16:24] <voidDotClass> purplefox_, i see, so HttpServerOptions().setIdleTimeout() is where to change the 2 hr default time out?
[01:16:37] <purplefox_> no, that's not the tcp timeout
[01:16:42] <voidDotClass> and pretty sure i had it running upto nearly 20 mins and it didnt time out, but that was in m3/m4
[01:16:58] <voidDotClass> purplefox_, then whats the setting to change the 2 hr timeout?
[01:17:05] <purplefox_> well i just run your exact test you gave me, and change the timeout to 5 seconds and it works fine ;)
[01:17:23] <voidDotClass> so that'd work with pulling out cable too?
[01:19:22] <voidDotClass> what setting has to be set to make it timeout in case of pulling out cable / powering off device?
[01:21:12] <purplefox_> you need to google this… iirc, if no data has been sent across the socket for 2 hours then it will timeout UNLESS TCP keep alive is enabled. to actually change the timeout, i think that is something you have to configure on the operating system
[01:21:15] <purplefox_> not in java
[01:21:59] <purplefox_> (btw 2 hours is OS dependent, but that seems to be the normal)
[01:22:32] <voidDotClass> purplefox_, so HttpServerOptions().setIdleTimeout wont cause it to timeout the conn in case of cable being pulled?
[01:22:47] <voidDotClass> or conn being otherwise idle?
[01:23:02] <purplefox_> i think it will timeout, but I suggest you try it
[01:23:28] <voidDotClass> all right.
[01:23:35] <purplefox_> setting the idletimeout should cause vert.x to close the connection if it receives no data
[01:23:44] <purplefox_> i tried it here and it works for me
[01:23:51] <voidDotClass> i think netty has an idle timeout worker or some class like that, right?
[01:23:59] <voidDotClass> which is initiated in httpserverimpl
[01:23:59] <purplefox_> yes, that's what we use
[01:24:01] <voidDotClass> i believe
[01:24:14] <purplefox_> the actual timeout happens in netty
[01:24:18] <voidDotClass> purplefox_, you tried cable being pulled too?
[01:24:23] <voidDotClass> or just the test?
[01:24:26] <purplefox_> no
[01:24:29] <voidDotClass> ok
[01:24:29] <purplefox_> i just ran your tets
[01:24:32] <voidDotClass> kk
[13:39:25] <purplefox_> temporal_: are you there?
[18:09:36] <andyhedges_> With vert.x 3 when I created multiple instances of my verticle, programatically using deployVerticle I get java.lang.IllegalStateException: Failed to create cache dir
[18:10:27] <andyhedges_> both verticle try to create the same .vertx/file-cache-[UUID] director
[18:10:38] <andyhedges_> and one fails because it already exists
[18:10:52] <andyhedges_> I'm clearly doing something wrong but can't figure out what
[18:11:06] <andyhedges_> Any ideas?
[18:16:41] <purplefox_> andyhedges_: do you have an example andy?
[18:42:49] <andyhedges_> Not a simple one, I'll create on this evening
[19:19:58] <andyhedges_> OK, here's an example http://pastebin.com/fBHpFBWQ
[19:20:46] <andyhedges_> Seems to be a race condition as it doesn't always happen