request stalled for a long time occasionally in chrome

I once encountered a similar problem. The cause of the problem is that every browser has a limit to the maximum number of TCP connections to a server. For chrome, the limit is six. The problem is more prominent when you are using a proxy server, because all the requests go the same server (the proxy server).

Chrome doesn't allow you to change this limit. It shouldn't in fact. If you want to know more about why this limit exists, and what are the limits for other browsers, you can read this article.

The reason why this limit is rarely a problem is because multiple HTTP requests to the same host are mostly sent consecutively, rather than parallely, preferably over the same TCP connection.

If this problem occurs to you frequently, then the reason might be:

1. Server doesn't support persistent TCP connection: If the problem occurs only when accessing a particular server, the reason might be that chrome is fetching multiple resources (like images, CSS files, etc) on parallel connections. Since, in your case, the server is on your local network, you might want to ask the server's administrator to add support for persistent TCP connections.

2. Multiple persistent connections are open: If you are working behind a proxy server, then downloading multiple files simultaneously or opening sites which keep a TCP connection open might be the cause of your problem.To get rid of it, all you can do is to not download many things simultaneously (or download in a different browser, if you have to).

PS: The error net_error = -101 (ERR_CONNECTION_RESET) is not due to invalid headers, it is because of the timeout, waiting for some previous connection to the server to close.

Similar issue here and it appears that after a while, approx 3 minutes a socket chrome is trying to use is closed (I assume) by the OS.

This is listed as a bug in the chromium forum as well. I'm guessing lack of some sort of "keep-alive" mechanism.:https://code.google.com/p/chromium/issues/detail?id=447463

My error message is slightly different but it could be due to my application making the calls over SSL. Here's what I see in chrome://net-internals:

First chrome finds an existing socket and the request is associated with it (HTTP_STREAM_JOB):

    t=1572 [st=0]    HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION                     --> source_dependency = 1347215 (HTTP2_SESSION)    t=1572 [st=0]    HTTP_STREAM_JOB_BOUND_TO_REQUEST                     --> source_dependency = 1348612 (URL_REQUEST)    t=1572 [st=0] -HTTP_STREAM_JOB

Then back in (URL_REQUEST) you will see it time out, note the 10 seconds lapse in time from t=1572 to t=11573:

    t= 1572 [st=    0]  HTTP2_SESSION_SEND_DATA                        --> fin = true                        --> size = 48                        --> stream_id = 3    t= 1572 [st=    0]  HTTP2_SESSION_UPDATE_SEND_WINDOW                        --> delta = -48                        --> window_size = 2147483551    t=11573 [st=10001]  HTTP2_SESSION_CLOSE                        --> description = "Failed ping."                        --> net_error = -352 (ERR_SPDY_PING_FAILED)

Clearly there is a timeout when chrome attempts to adjust the window size on the existing socket. I assume this is due to inactivity on the socket.

I'm going to try to implement some sort of heartbeat request at perhaps 60 sec interval to see if the issue still persists. I'll post an update with results.

UPDATE:

Added the following code to javascript that's loaded on every page. This is retrieving an empty html doc from the public root:

    $(document).ready(function() {        $.keepalive =                     setInterval(function() {                   $.ajax({                      url: '/ping.html',                      cache: false                   });                         }, 60000);        });

This appears to have helped keep the socket open even with the sample below showing approx 6 minutes between "real" calls:

At 570B per call in 60 sec intervals the ping call would add around 800kb of bandwidth usage per 24 hrs (per browser session). I'm not sure how much CPU overhead on the server this would cause.

For comparison, the BEFORE:

There has to be a better solution but i haven't been able to locate one yet.