Hi Alexandru,
Thank you for your suggestions. I can send the response header, but that doesn't mean the client will close the connection. Perhaps it should, but I'd like a firmer guarantee. For example, in a DDOS situation you certainly couldn't expect an attacker to politely respect a server's request to back off. ;) I'd like the server to proactively manage its network resources in a defensive way when under a heavy load.
We've actually run into the problem of TCP port exhaustion running a play app in an ordinary production scenario. The server holds the connections open too long and the kernel runs out of ports to allocate. The server is "running", but the response time balloons from milliseconds to tens of seconds for the simplest requests. This isn't a limitation of the hardware or the kernel. We have no trouble if we put a reverse proxy in front of our play server and configure the proxy to disable persistent connections. This configuration actually suits our production traffic pattern quite well, so if it's something that play supported we could make excellent use of it.
There are probably other good reasons to put a proxy in front of a play app, but it was performing brilliantly until we ran into this issue. Now I'm curious to see what it could do without this limitation. I'd love to hack in a change and take it for a spin, but I've got other things I have to put ahead on my task list.
If anyone else has encountered and worked around the same issue, please share. :)
Cheers,
Michael