Closed Bug 1160013 Opened 6 years ago Closed 5 years ago

ONLY BAD SLAVES HIT Intermittent cache-match.https.html | Cache.matchAll with no matching entries - Test timed out and many more

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox39 --- unaffected
firefox40 --- affected
firefox41 --- affected
firefox-esr31 --- unaffected
firefox-esr38 --- unaffected

People

(Reporter: philor, Assigned: bkelly)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

CachePushStreamChild should hold the parent DOM object alive. r=baku
4.35 KB, patch
baku
: review+
Details | Diff | Splinter Review 
No description provided.
I ran this in DEBUG mode on try and its hitting an assert I added in bug 1160147.  I forgot to have the CachePushStreamChild hold the Cache DOM object alive like I intended.  This patch fixes that.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
Attachment #8601220 - Flags: review?(amarchesini)
Attachment #8601220 - Flags: review?(amarchesini) → review+
Comment 33 shows this patch is not adequate to fix all errors.  I think it should reduce the frequency of this intermittent, though.
Keywords: leave-open
I think this one has to do with how the test is doing the pre-populated cache.  Its also only hitting on main thread, so it could be an PBackground actor startup thing.
No longer blocks: 1161055
Actually, it happens on worker.  So not a PBackground actor startup thing.
So this file creates 21 Cache objects with most of them each having 12 entries put into them.  In addition, each Cache object is deleted before being created.  This reflects about 294 operations being scheduled roughly at the same time.

It seems plausible Cache is running into a performance problem here.
On my fast desktop I see some ActionRunnables take 100ms to start and 200ms to complete.  200ms * ~300 requests is 60 seconds.  There should be some operation overlap and that was the worst case I saw, but triggering the timeout seems to be in the realm of possibility.
On the try server during one of these failures I see ActionRunnables taking anywhere from 3 seconds to 10 seconds to execute.  I think this is the culprit.

I will attempt to fix by implementing the lowest hanging optimization; keeping the sqlite database connection open between requests.
Depends on: 1134671
Depends on: 1162211
I was unable to conclusively resolve this today.  Try was acting up.  I have some patches which might land and fix it, but I'm not holding my breath.  I will look at it again when I return from PTO next week.
This try build shows fairly promising results for silencing this intermittent:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=c7257315c37a

Unfortunately those patches introduce a perma-orange on mulet M1:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=d3347a2c69b7

So this will have to wait until I return next week.  Sorry!
Depends on: 1162342
Summary: Initermittent cache-match.https.html | Cache.matchAll with no matching entries - Test timed out and many more → Intermittent cache-match.https.html | Cache.matchAll with no matching entries - Test timed out and many more