If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Investigate why HTTP/2 test runs over 2 different connections

RESOLVED FIXED in mozilla38

Status

()

Core
Networking: HTTP
--
minor
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: nwgh, Assigned: mcmanus)

Tracking

Trunk
mozilla38
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [spdy])

Attachments

(2 attachments)

I noticed this while debugging my tests for bug 1091263. As it turns out, we end up with two different HTTP/2 sessions when running test_http2.js. The first connection is used by the first test, and the second connection is used by all subsequent tests (unless there's a test that explicitly causes a new connection). This happens regardless of which test is first, and regardless of how many tests are in the suite. This was really annoying when I was running just a new subset of the tests that were supposed to share a connection, and they didn't. Once I re-enabled the rest of the tests (that were run before my new tests), everything was fine.

This isn't the end of the world, but we should see if we can figure out why this happens, and also if it ever happens in the real world.
(Assignee)

Comment 1

3 years ago
I think I diagnosed this on the test_spdy side, which sees a similar thing.

A sepculative connect starts a connection, and the tcp handshake completes before the connection manager has a transaction for it yet. (in this case that's cause the connect is to localhost - so its wicked fast). So the connection manager drives the ssl handshake with a null transaciton.

but before the null transaction has completed the http request arrives in the connection manager and that starts a new connection up because there are no idle or active-spdy connections.

give it a few milliseconds and you've got 2 sessions.

There actually is code in makenewconnections() that looks for a sepculative half open connection.. and if it finds such a thing it claims it for itself rather than making a new connection. I think the issue can be fixed by extending that logic to active null transactions as well.
(Assignee)

Updated

3 years ago
Blocks: 1102923
(Assignee)

Comment 2

3 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbf8c15ff4ba
(Assignee)

Comment 3

3 years ago
Created attachment 8555851 [details] [diff] [review]
claim conns with null transactions instead of starting new ones
Attachment #8555851 - Flags: review?(hurley)
(Assignee)

Updated

3 years ago
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #8555851 - Flags: review?(hurley) → review+
(Assignee)

Comment 4

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/050e9b432799
(Assignee)

Comment 5

3 years ago
Created attachment 8556095 [details] [diff] [review]
only claim null transactions for your connection if KA eligible
Attachment #8556095 - Flags: review?(hurley)
Attachment #8556095 - Flags: review?(hurley) → review+
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/c4cccb7acc1b
https://hg.mozilla.org/mozilla-central/rev/050e9b432799
https://hg.mozilla.org/mozilla-central/rev/c4cccb7acc1b
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.