1370340 - Carrying class-of-service flags to redirected channels causes infinite page loading on www.walmartmoneycard.com/login

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Thomas Wisniewski]

On a fresh profile with today's nightly, www.walmartmoneycard.com/login doesn't load. Mozregression pointed me to bug 1356538. I just built a fresh copy of inbound with that patch reverted to test, and the page loads fine without it. (Note that I created fresh scratch profiles between tests in an attempt to rule out caching issues).

My mozregression result, in case it helps:
>INFO: Last good revision: 3c355512ec28828499768ed1af25e15bda3141b8
>INFO: First bad revision: b7f8c279b92268625473c916e9f34b307c924625
>INFO: Pushlog:
>https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3c355512ec28828499768ed1af25e15bda3141b8&tochange=b7f8c279b92268625473c916e9f34b307c924625

Comment 1

[Honza Bambas (:mayhemer)]

Thanks for this precise report!  I will look into it.

Comment 2

[Honza Bambas (:mayhemer)]

OK, so, bless you log analyzer!  The thing here is following:

- there are some transactions blocking in the window's request content (rc)
- later there are also some (6+) that are not blocking, hence, are put to the queue as blocked
- some of the blocking transactions are redirected
- before bug 1356538 the redirected transactions didn't get the blocking flag
- but now, they get it!
- but, they are not given (as part of the redirect setup) the correct tab id - it's left at 0

That leads to a situation that when we try to dispatch something on a reclaimed connection, we only try five transactions for the current tab id but we never try to dispatch those with tab id = 0.

This is a logical deadlock - there are blockers with tab id = 0 we never try to dispatch but there are blocked transactions for tab id = active tab we try to dispatch instead.

An immediate fix is to carry the window id on redirect (no, we don't do that..), so that the blocking transactions will be found in the correct queue.

The true fix (for a follow up) is to fix the background tab dispatch logic a bit so that blockers will get dispatched.  Have to think more about it how.

Comment 3

[Honza Bambas (:mayhemer)]

Attachment: v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels)

See the previous bugzilla comment for explanation.  There will be followups...

Comment 4

[Honza Bambas (:mayhemer)]

Comment on attachment 8876317 [details] [diff] [review]
v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels)

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

Comment 5

[Honza Bambas (:mayhemer)]

Comment on attachment 8876317 [details] [diff] [review]
v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels)

Dragana, if you get a chance to get to this one-liner no later than on Monday, I would greatly appreciate it.  This is major issue fix.

Thanks!

Comment 7

[Honza Bambas (:mayhemer)]

Attachment: v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels)

This one actually builds...

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

Comment 8

[Dragana Damjanovic [:dragana]]

I was just about to review it :)

Comment 9

[Honza Bambas (:mayhemer)]

Thank you both! :))

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b9dc09ee4793
Carry TopLevelOuterContentWindowId to redirected HTTP channels. r=mcmanus

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/b9dc09ee4793