New issue
Advanced search Search tips

Issue 718900 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Creation error rate much higher on Android than elsewhere.

Project Member Reported by morlovich@chromium.org, May 5 2017

Issue description

... and high enough that I am worried about it.

(See SimpleCache.Http.EntryCreationResult, SimpleCache.Http.SyncCreateResult)

Most of these failures are due to FILE_NOT_FOUND, which suggests that the cache directory is deleted --- perhaps via the buttons in Android UI?

Hand-testing shows that pressing those will indeed cause a burst of entry creation failures, until the system is quiet enough that we take an 
index snapshot (or Chrome gets restarted).

 
Project Member

Comment 1 by bugdroid1@chromium.org, May 15 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2d841835e729da2bef43897070bc83568e783b4c

commit 2d841835e729da2bef43897070bc83568e783b4c
Author: morlovich <morlovich@chromium.org>
Date: Mon May 15 15:20:07 2017

We seem to be failing a non-trivial portion of creates on Android
in this case, and it's easy enough to just mkdir it --- that will
happen eventually on index saving, anyway, but may take a long time
in the case where the user is actively browsing.

BUG= 718900 

Review-Url: https://codereview.chromium.org/2862943002
Cr-Commit-Position: refs/heads/master@{#471770}

[modify] https://crrev.com/2d841835e729da2bef43897070bc83568e783b4c/net/disk_cache/entry_unittest.cc
[modify] https://crrev.com/2d841835e729da2bef43897070bc83568e783b4c/net/disk_cache/simple/simple_synchronous_entry.cc

So I missed something when I first noticed this, which is rather important 
wrt to evaluating both the condition and the fix: the error rate seem to spike for the old milestone as it begins being replaced by the new one. The graph is much easier to read when split by milestones as such.

(And thus far, Beta 60 seems to have about half the error rate, which is somewhat disappointing, plus it's a bit early to be sure)

Hmm, actually SyncCreateResult being Platform File Error is practically zeroed out in Beta 60, and from those that do exist NOT_FOUND is a small portion; so likely there is some other failure factor.

Probably true for dev/canary as well, though I have to filter for version = dominant to test stuff newer than 3101.

Though, error rates testing for that seem much lower, so maybe the app is a factor, too. 
Ah, EntryCreationResult counts both Create and Open, so SyncOpenResult is useful to look at, too, and it provides the rest, I think, and mostly due to NOT_FOUND, too --- which we still expect to happen due manual clear, so that doesn't contradict that hypothesis (nor confirms it).

Status: Fixed (was: Started)
Fixed in 60. 

Sign in to add a comment