Network requests stuck in pending state |
||||||
Issue descriptionChrome Version : Chrome 69 URLs (if applicable) : https://colab.corp.google.com Other browsers tested: Safari: Firefox: Edge: What steps will reproduce the problem? (1) File-> Save a copy in Drive. (2) In the new document, save multiple times. (3) What is the expected result? All saves complete. What happens instead? A number of our users are seeing the save operations hang. We've had difficulty reproducing this issue ourselves, but a significant number of Googlers have been reporting this. Reports started in early August and have been ramping up since then. See: b/112431524 b/116274455 b/117235307 From b/117235307 we were able to capture a trace with chrome://net-export/ as the user was experiencing the issue and near the end of the trace we see: t=7743410 [st= 0] +REQUEST_ALIVE [dt=25531+] --> priority = "LOWEST" --> url = "https://clients6.google.com/upload/drive/v2beta/files..." t=7743410 [st= 0] +DELEGATE_INFO [dt=25531+] --> delegate_blocked_by = "ResourceScheduler" t=7768941 [st=25531] The trace continues for another 20 seconds but there is no progress on these requests. Access to the trace can be requested from https://drive.google.com/file/d/1UO5Q1lz0y7zz0xfeBf5nyltGyHEP7RiA/view Also from b/117235307 you'll see that the network requests are stuck in pending state. Similarly, https://b.corp.google.com/issues/112431524#comment23 has a number of network requests stuck in pending state.
,
Oct 3
Note that we've only had reports from @google.com users, no external users have reported it on the external Colaboratory. One difference between the two is that external Colaboratory has 2 fewer long-polling network requests continually running. Not sure if this is related to crbug.com/837771.
,
Oct 4
,
Oct 4
Seems blocked in the chrome network stack rather than blink. //services/network/resource_scheduler.cc This also may be related to the socket pool issue of 872284 tbansal@, IIRC, you ran an experiment in this layer. Could you take a look or find a right person to investigate the problem?
,
Oct 4
,
Oct 4
I can confirm that it can happen when the user is in 3 experiments (all of which I am running). The bug does not affect external users, and affects ~15% of Google users. To repro this, start Chrome with switch: --force-effective-connection-type=3G. The experiments kick in only when the user is signed in with google.com account in Chrome. The 3 experiments: 1. DelayRequestsOnMultiplexedConnections: Enabling this experiment allows Chrome to throttle requests to HTTP 2.0 servers. 2. LowPriorityIframes: This causes requests in iframes to be marked as low priority, and can cause them to be throttled in presence of high priority requests. 3. ThrottleDelayable: This causes Chrome to start throttling low priority requests if there are too many high priority requests in-flight. When all 3 experiments are enabled, and when effective-connection-type is detected as 3G, then XHRss from iframes will be marked as low priority, and so can be throttled if there are too many high priority requests in-flight (in this case: XHRs from main frame). I am going to disable experiment (2) and (3) for now which we were not planning to launch anyways.
,
Oct 4
This should be fixed now (pending the user restarting Chrome).
,
Oct 25
Hey Tarun, let me confirm that this issue won't happen after m70, right? Or still need to wait a target mileston?
,
Oct 25
This was a Finch experiment, and has been turned off. Users should not have to wait for this to be fixed. M-69 label seems appropriate.
,
Oct 26
I see, perfect! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by piatek@chromium.org
, Oct 3