Unfortunately, I was unable to implement this feature. Jetty uses different processing model and it assumes that if request started being processed it needs to finish processing on its own - no support for a timeout.

I tried to replace executor used by Jetty but it is used not only for processing requests but also for waiting for incoming requests in selectors select() method. As the result, I had very high CPU usage all the time (due to restarted threads for waiting for incoming requests).

I think that we need to live with that and as Jetty is rather clever in things it does we should be fine.

As I mentioned Jetty does not have a timeout, so it would properly process requests from #7503. I've found an issue on the client side. In StatisticsUploader::uploadData(String) method is following code

		final int i = 5;
		conn.setConnectTimeout(i * 1000);
		conn.setReadTimeout(i * 1000);

which forces connection to throw exception if:

• connection establishment took over 5 seconds
• there was no response from the server in 5 secods (cause of our bug)

Second condition results in throwing exception java.net.SocketTimeoutException: Read timed out from #7503. In case of error on the HTTP API side connection would be closed without any data, but you would get an exception about the connection being closed by the server.

Thank you for spotting this. I've increased timeouts to 1 / 5 minutes (connection / read respectively)