wai-websockets long quiet connections

[phadej]

Is it possible to have different kill timeout for threads serving websocketsApp. With otherwise reasonable whole warp instance wide 30 seconds timeout bundled chat example application is not usable in quiet chat rooms?

[snoyberg]

I think as implemented right now, there isn't any timeout on websockets apps. Are you seeing different behavior?

[phadej]

With server.lhs modified as in phadej/wai@yesodweb:c359f1b...phadej:7546e24

Started server, opened connection in three different browsers and done nothing for a while:

 % dist/build/wai-websockets-example/wai-websockets-example
http://localhost:9160/client.html
2014-03-10 14:24:18.880625 UTC
canary joined
2014-03-10 14:24:24.296978 UTC
safari joined
2014-03-10 14:24:39.506853 UTC
firefox joined
2014-03-10 14:25:08.690782 UTC
safari disconnected
async exception: safari
thread killed
2014-03-10 14:25:08.691668 UTC
canary disconnected
async exception: canary
thread killed
2014-03-10 14:25:38.689255 UTC
firefox disconnected
async exception: firefox
thread killed

I tried with example in websockets, it's connections stay open indefinitely (at least over lunch ~ half an hour).

[snoyberg]

Ahh, good point. I'm not opposed at all to having longer timeouts for raw connections, but most likely you're going to want to add a ping to the protocol to prevent these kinds of timeouts.

[phadej]

Sending ping-pongs doesn't just work. You have to disable warp timeouts and handle liveness inside websocket application, that you have to do anyway.

TL;DR

I tried adding ping-pongs and them didn't work. The timeout manager strikes still as ping-pongs are read/written inside websocket application, so there aren't any automatic timeout tickling.

It's also impossible to tickle by hand (breaking abstractions) as you cannot get Handle from InputStream/OutputStream in Connection.

For simple client-based ping look at: phadej@5d2a23a :

% dist/build/wai-websockets-example/wai-websockets-example
http://localhost:9160/client.html
2014-03-10 17:58:46.63462 UTC
canary joined
2014-03-10 17:58:51.909964 UTC
firefox joined
2014-03-10 17:58:56.626908 UTC
canary: ping
2014-03-10 17:58:58.68766 UTC
safari joined
2014-03-10 17:59:01.910677 UTC
firefox: ping
2014-03-10 17:59:06.627879 UTC
canary: ping
2014-03-10 17:59:08.687777 UTC
safari: ping
2014-03-10 17:59:11.909522 UTC
firefox: ping
2014-03-10 17:59:16.627705 UTC
canary: ping
2014-03-10 17:59:18.687824 UTC
safari: ping
2014-03-10 17:59:21.908157 UTC
firefox: ping
2014-03-10 17:59:26.627857 UTC
canary: ping
2014-03-10 17:59:28.687115 UTC
safari: ping
2014-03-10 17:59:31.907194 UTC
firefox: ping
2014-03-10 17:59:36.628344 UTC
canary: ping
2014-03-10 17:59:38.412235 UTC
safari disconnected
async exception: safari
thread killed
2014-03-10 17:59:38.414783 UTC
firefox disconnected
async exception: firefox
thread killed
2014-03-10 17:59:38.41516 UTC
canary disconnected
async exception: canary
thread killed

[snoyberg]

OK, that's just a bug, and not a surprising one, given that I thought I'd disabled timeout handling entirely for raw responses. For now, I've pushed a conservative commit: tickling the timeout handler each time a send or receive occurs in a raw response (129b332).

[phadej]

Seems to work for my sample app (with client ping)! Thanks!

[phadej]

Should we create a new issue about disabling timeout handling for the raw responses, to start a discussion about?

[snoyberg]

Yes, please do.