New issue
Advanced search Search tips

Issue 800510 link

Starred by 3 users
Status: Assigned
Owner:
b...@chromium.org
Cc:
mmenke@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

HTTP2 connections block for 5 minutes when resuming

Reported by con...@superhuman.com, Jan 9 2018 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Example URL:
https://mail.superhunan.com

Steps to reproduce the problem:
Not entirely sure. One of our users has been seeing this intermittently for a while, and I finally got a net-export today.

1. It seems create an HTTP 2 connection 
2. Change location / put your laptop to sleep and wake it up.
3. Continue trying to use the HTTP 2 connection

What is the expected behavior?
Everything works instantly.

What went wrong?
Instead of reconnecting instantly, the connection blocks all requests for about 5 minutes and then resumes.

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: OS X 10.13.2
Flash Version: 

This only seems to be affecting one user, so it's possibly something on the internet getting in the way.
chrome-net-export-log (1).json
6.3 MB View Download

Comment 1 by mmenke@chromium.org, Jan 9 2018

Components: -Internals>Network Internals>Network>HTTP2
Thanks for the log!  At the start of the log, we have a bunch of pending requests to mail.superhuman.com that have been around for 70 to 200 seconds (Most look to be hanging gets for chat an the like).  Then they all get ERR_SPDY_PING_FAILED at once, and we try them.  Everything seems to work fine after that.  There are requests that seem to work fine while other requests are hung, too.

I'm not our resident H2 expert, but I believe when there's a network change, we keep previous H2 requests alive, but all new requests use a new session.  So old requests are effectively blocked until the old session times out, and that may be causing issues here?

[bnc]:  Does that sound right?

Comment 2 by con...@superhuman.com, Jan 9 2018 

Thanks for the comment.

That might be the case. Though I think from what he's describing, he's opening Superhuman again, which I would have thought should generate new requests. Is it possible they're being scheduled on these blocked connections?

If it makes a difference, we do have a service worker in the mix too.

Comment 3 by krajshree@chromium.org, Jan 10 2018

Labels: Needs-Triage-M63

Comment 4 by b...@chromium.org, Jan 11 2018

Owner: b...@chromium.org
On Mac, all requests should fail as soon as the IP address changes: https://cs.chromium.org/chromium/src/net/spdy/chromium/spdy_session_pool.cc?q=OnIPAddressChanged  Note, however, that I do not see any ERR_NETWORK_CHANGED entries in the attached log.

PING timeout is only 10 seconds, and a PING frame is sent right before a request if there has not been any reads for at least 10 seconds.  However, after the computer wakes up, if there is no IP address change event, and there is no new requests on the same connection, then indeed the requests take some time to fail.

Comment 5 by mmenke@chromium.org, Jan 11 2018

Cc: mmenke@chromium.org
Status: Assigned (was: Unconfirmed)
Hrm, actually...  URLRequestJob::OnSuspend should abort all requests when we enter suspend mode, though it doesn't close sockets or HTTP2 sessions (I'd like to move it down to the socket layer, but haven't had a chance, and likely won't for quite some time).

So I'd expect us to cancel requests, but for the H2 sessions to remain alive, if there's no network change event (Which could explain the observed behavior, if the IP address didn't change).  But that's not what we're seeing in the log - stale requests are remaining alive.
►

Sign in to add a comment