Add connection state to RequestHeader

[pauldraper]

When a Play server slows down, it builds up a large backlog of requests, which is nearly unlimited due to Netty's eager acceptance of new connections.

The clients will come, fill the OS's TCP buffer with an HTTP request, time out, leave, and perhaps even retry. Play continues to process requests for clients who don't care, slowing down the response times for the arriving clients. A brief period of high load can cause sustained client timeouts for a long time after.

A limit on current connections is one way to solve this. Checking the current connection state on the RequestHeader is one way.

[wsargent]

This is something that Akka-HTTP will have more of a handle on, since it's got backpressure handling / flow control built into it, but it's a ways off. Regarding possible fixes -- yes, rate limiting on input is one possibility, but is best discussed on the mailing list than on the issue tracker.

[pauldraper]

@wsargent, thanks. I think my explanation could have been better. I meant for this issue to be very specific -- "make connection status available" -- rather than a general discussion of load handling strategies. I can move this to the mailing list if still desired though.

I just created a patch for 2.3.x for my own purposes, as an example of how this might work: lucidsoftware#1
(I realize that 2.3.x is past active development, but I currently use it and am more familiar with it. Again, this is just an example patch.)

[cchantep]

I think this should first be discussed on the MailingList.

[richdougherty]

I know there is a lot of discussion on the mailing list about whether we should expose any HTTP state in the RequestHeader, but I do see some value adding a method like isKnownToBeCancelled to the RequestHeader object. If we had a method like this then there are probably several optimisations that we could make to Play.