Correct video url: https://drive.google.com/open?id=0B5pZ43DhqaQDRzZtZTIzcWNnY0E

Hrm, I was thinking that our connection timeouts were 30 seconds...But looking at the code, it's actually 4 minutes (+30 for HTTPS, +30 for proxies):  https://cs.chromium.org/chromium/src/net/socket/transport_client_socket_pool.cc?q=file:Src/net/socket+%5C+.*timeout&sq=package:chromium&l=80&dr=C

We don't close connection attempts when socket requests are cancelled, so this seems to be expected behavior.

@mmenke
We don't close connection attempts when socket requests are cancelled, so this seems to be expected behavior.

Is there a reason for such behavior? Or just closing connection attempts is not beneficial?

I assume this is because connection attempts are highly correlated.  Suppose you go to foo.com.  We establish a connection, get the main resource.  It requests two more resources on the same domain, one reuses the original connection, other starts establishing a new connection.  The first subresource request completes before the connection completes, so we reuse its connection for the second subresource.  The connect attempt continues, as it's likely we'll still need more requests from the domain.

Connection attempts are generally seen as low cost, and potentially high latency benefit, if we keep them around.

Note that like most old behavior, this was written when Chrome was a desktop-only browser.  Mobile may change things, or the original assumptions may not be correct (Or may no longer be correct).  The logic also predates preconnect, which could make the logic either more useful, or less.

@mmenke
Thx!

But in this case connection is not successful. Is it still useful to keep it around?

We don't keep around unsuccessful connection attempts.  Note that in the log, it's spending that time trying to connect.  Something is apparently blackholing the connection attempt (We never hear anything bad.  No ICMP error, etc).  There's only so much we can do on a network where The Powers That Be are doing something that unfriendly to us.

Put another way, we don't know that the connection attempt isn't succeeding - it could be we're on a really bad network, in which case, it would actually make more sense to keep around the connection attempt, because of the bad latency (Or packet loss)

@mmenke
Thx!

No problem.  If you want to spend some time investigating this space, happy to work with you.  There may be wins on mobile here, in particular, in terms of battery, memory, or even handling of poor networks (If we close sockets when you reload a hanging page, killing old sockets and creating new ones may be useful, or it may just make things worse).

[+xunjieli] who's investigating memory use, and may take a look at idle sockets at some point, though connecting sockets is slightly different potential issue.

And marking as available, to get it out of our bug triage queue.

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

This seems to be WAI for me. Socket connect attempts, as mmenke@ said, are seen as low cost and of potentially high latency impact. Canceling socket attempts early might end up being worse for the users. We reduced the amount of memory usage for hanging connects ( Issue 690915  is an example), so the concern on memory is somewhat alleviated. 

I'll close this one as WontFix as it's been a year without activity on this bug and the current behavior is WAI. Please feel free to re-open.