New issue
Advanced search Search tips
Starred by 19 users
Status: Duplicate
Merged: issue 472740
Owner:
Closed: Jul 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature



Sign in to add a comment
Pages can get blocked in "Waiting for Cache" for a very long time
Project Member Reported by eroman@chromium.org, Jun 8 2010 Back to list
As I was debugging issue 2016, I ran into an issue where Chrome's HTTP cache reader/writer queue doesn't work well for long-lived requests.

Basically here is the situation:

The site author has a long-lived XHR being used to stream a slow response from the server. This XHR response is cachable (it is just really slow). They kick off the XHR asynchronously, and as data slowly arrives on it, update the progressive load of the webpage. Cool.

Now what happens if you try to load this page in multiple tabs of Chrome is:
The first page starts to load just fine, but the second one does nothing.
What has happened, is the background XHR of the first page load has acquired an exclusive lock to the cache entry, and the background XHR of the second page is stalled at "Waiting for cache..." trying to get a reader access to the cache entry.

Since the first request can takes minutes, this is a problem.


A couple ideas on what we might do here:

(a) [Flexible but complicated] Allow cache readers WHILE writing is in progress. This way the first request could still have exclusive access to the cache entry, but the second request could be streamed the results as they get written to the cache entry. The end result is the second page load would mirror the progress of the first one.

(a) [Naive but simpler] Have a timeout on how long we will block readers waiting for a cache entry before giving up and bypassing the cache.
 
Labels: Mstone-7
Status: Assigned
Labels: -Type-Bug Type-Feature
See http://codereview.chromium.org/111005 for a previous attempt to implement the second proposal (context: issue 6697).

Labels: -Mstone-7 Mstone-8
Labels: -Mstone-8 Mstone-9
Labels: -mstone-9 Mstone-10
Given our current velocity, we need to punt 500 bugs from m9.  Moving p2 bugs, that are not started and have an owner, to the next milestone.  If this issue absolutely needs to be fixed in the current milestone please move it back, however, at this time the focus should be on p1 bugs.
Comment 6 by kerz@chromium.org, Dec 9 2010
Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Labels: -Mstone-11 Mstone-12
Labels: -Mstone-12 Mstone-13
Labels: -Mstone-13 Mstone-14
Labels: -MovedFrom-10 -Mstone-14 Mstone-16
Even though I have a partial CL to modify the lock behavior, I doubt I'll finish it before M16.
Labels: -Mstone-16
Project Member Comment 12 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
 Issue 293517  has been merged into this issue.
Comment 14 by shach...@gmail.com, Nov 27 2013
This bug has been pushed to the next mstone forever...and is blocking more bugs (e.g https://code.google.com/p/chromium/issues/detail?id=31014)and use-cases same video in 2 tags on one page, and adaptive bit rate html5 video streaming whenever that will kick in. Any chance this will be prioritized?
Recently there was someone looking at giving it another try... I'd have to see if there was any progress there.

If not, I may try to fix it in Q1.
Comment 16 by jkarlin@google.com, Nov 29 2013
I intend to work on it but need to wrap up another bit of work first.  Will likely get started on this around late Q4 early Q1.
Will the solution consider the subsequent bug: https://code.google.com/p/chromium/issues/detail?id=31014 ?
Cc: davidben@chromium.org
What I was considering would exclude range-requests so I don't believe it would solve 31014.  I know that davidben@ is also looking at this issue, adding him.
Project Member Comment 19 by bugdroid1@chromium.org, Jun 24 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8aacaf38e85c45876c72ea77e36ef17e5ab69c26

commit 8aacaf38e85c45876c72ea77e36ef17e5ab69c26
Author: rvargas@chromium.org <rvargas@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jun 24 05:33:41 2014

Http cache: Implement a timeout for the cache lock.

The cache has a single writer / multiple reader lock to avoid downloading the
same resource n times. However, it is possible to block many tabs on the same
resource, for instance behind an auth dialog.

This CL implements a 20 seconds timeout so that the scenario described in the
bug results in multiple authentication dialogs (one per blocked tab) so the
user can know what to do. It will also help with other cases when the single
writer blocks for a long time.

The timeout is somewhat arbitrary but it should allow medium size resources
to be downloaded before starting another request for the same item. The general
solution of detecting progress and allow readers to start before the writer
finishes should be implemented on another CL.

BUG=6697,  46104 

Review URL: https://codereview.chromium.org/345643003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@279326 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 20 by bugdroid1@chromium.org, Jun 24 2014
------------------------------------------------------------------
r279326 | rvargas@chromium.org | 2014-06-24T05:33:41.209667Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_transaction.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_transaction.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/mock_http_cache.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/mock_http_cache.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_unittest.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.h?r1=279326&r2=279325&pathrev=279326

Http cache: Implement a timeout for the cache lock.

The cache has a single writer / multiple reader lock to avoid downloading the
same resource n times. However, it is possible to block many tabs on the same
resource, for instance behind an auth dialog.

This CL implements a 20 seconds timeout so that the scenario described in the
bug results in multiple authentication dialogs (one per blocked tab) so the
user can know what to do. It will also help with other cases when the single
writer blocks for a long time.

The timeout is somewhat arbitrary but it should allow medium size resources
to be downloaded before starting another request for the same item. The general
solution of detecting progress and allow readers to start before the writer
finishes should be implemented on another CL.

BUG=6697,  46104 

Review URL: https://codereview.chromium.org/345643003
-----------------------------------------------------------------
Cc: -rvargas@chromium.org
Owner: ----
Status: Available
Project Member Comment 22 by sheriffbot@chromium.org, Jun 28 2016
Labels: Hotlist-OpenBugWithCL
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 23 by sheriffbot@chromium.org, Jun 28
Labels: Hotlist-Recharge-Cold
Status: Untriaged
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: -Internals>Network -Internals Internals>Network>Cache
Owner: shivanisha@chromium.org
Status: Assigned
Shivani: can you update the status of this bug? (I believe you were working on this area).
Mergedinto: 472740
Status: Duplicate
Since this is the cache lock issue, marking it as duplicate of 472740.

Some CLs for this have landed (which allow a transaction to start its headers/validation phase while another is writing the response body). Subsequent CLs to allow multiple transactions driving the reading from the network transaction simultaneously, are under review/in progress.
Sign in to add a comment