New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 324653 link

Starred by 135 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

waiting for available sockets

Reported by junkpo...@gmail.com, Dec 1 2013

Issue description

Chrome Version       : <Copy from: 'about:version'>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 6:
Firefox 20:
IE 7/8/9/10:
      Opera 12.16: OK
What steps will reproduce the problem?
1.
2.
3.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.


About 5 to 7 times per month for the entire day(12hrs), I am not able to open http://www.forexfactory.com/ from my google chrome even after restarting my computer. Initially it shows "waiting for www.forexfactory.com" in the status bar then it gives error that "Google can't find the site". Today I have seen "waiting for available sockets" message in status bar. At the same time I can easily open many websites. This is simply a big headache!

Thanks.

 
my Chrome Version       : Google Chrome	31.0.1650.57
Cc: srsridhar@chromium.org
Labels: Needs-Feedback
Able to navigate to http://www.forexfactory.com/ successfully on my Windows7 OS. 

Could you please specify the OS details on which you are facing this also. Also the attached .json file navigates to an error page. Please provide the same.
Cc: asanka@chromium.org
Labels: Cr-Internals-Network
Could you attach a net-internals log?

Comment 4 by d...@mail.ru, Jan 5 2014

I have the same problem with vk.com sometimes. Problem is worsening by the fact vk.com use JS excessively so it looks like no photo is shown in an album and no info. I realise the problem when open the same photo URL in different tab, chrome wrote "Waiting for available socket" in status bar. At the same time some photo URLs do not work and some are opening as usual. 

What is interesting... this problem illuminated when I open the same broken URL in incognito window. In detail: I had few tabs trying to load different URLs and they hang showing "Waiting for available socket" in status bar, I open one of thise URL in incognito tab, it was opened there (in incognito) and at the same time all this tabs opened their photos. Incognito somehow unhang this waiting loop. It is not related to the cache, because it unhang even tabs trying to load different URLs.

It is very hard to reproduce the problem. It appears time to time.

Comment 5 by d...@mail.ru, Jan 5 2014

Faced this bug once again. This time trick with incognito window doesn't work. Probably it was a coincidence.

It looks like some frontend of vk.com is broken. Chrome has keepalive http connection to this frontend and can't realize that it is already dead. May be it should send TCP keepalive packets everytime when new thread put in a queue for this HTTP keepalive connection? Yes it is annoying that HTTP keepalive and TCP keepalive is completely different thing but you probably understand what I mean. Anyway now chrome send TCP keepalives every 45 seconds and it is tooooo long to wait for in broadband internet era. Also some sites like vk.com have nearly hundred frontends and there can be one or two broken among them. Chrome should deal with this more robust. Now users are completely out of control. Some URLs to the site works some doesn't, but those who doesn't can be loaded in incognito at the same time, what an odd situation.
I get this as well, but mostly on Google domains. So gmail can be iffy, voice, search, etc.

The kicker is, like above, incognito works just fine.
Screenshot 2014-02-27 22.50.57.png
181 KB View Download
Net-internals attached here
net-internals-log (3).json
481 KB Download
And sorry to spam, but to cross these off the list, mitigation attempts:

1) Works perfectly in all other browsers (IE, Safari, Firefox, Opera)
2) Problem persists when ethernet is plugged into other port on same computer
3) Problem persists across router replacement
4) Have not experienced this problem in Linux VM on same machine (yet), though usage patterns are plainly different.
I am experiancing this issue with a custom HTML5/Javascript Web Application developed by my company. The files needed by the application are taking very long while seeing the 'waiting for available sockets' message
Cc: mattm@chromium.org
+mattm : Does this sound familiar?

tigerhawkvok: Thanks for the log, but it looks like it doesn't contain the events that caused the sockets to be stuck. Could you try starting the capture earlier? Perhaps at the start of a session?
asanka: "Waiting for available socket" isn't one I'm familiar.

That log is a bit weird though, there are a bunch of NETWORK_CHANGED, NETWORK_CONNECTIVITY_CHANGED,NETWORK_IP_ADDRESSES_CHANGED messages, like every ~10 seconds a new set of them.

Comment 12 by Deleted ...@, Mar 12 2014

I get this over and over again when opening multiple pages.  It is a chrome only issue.  chrome://net-internals/#sockets  It seems Chrome has a limit on the ssl_socket_pool of 6 Max Per Group and this madly slows down Chrome when opening many pages.  I have seen chrome take 50 minutes to open 20 pages while Firefox is already done 48 minutes prior.  I can recreate this over and over again.  Mike

Comment 13 by Deleted ...@, Mar 13 2014

Today, side by side, i opened 50 pages on Chrome and then 50 pages on Firefox.  Chrome is still spinning after 30 minutes.  it has opened about 3 of the pages. Firefox finished about 20 minutes ago.  This issue of "WAITING FOR AVAILABLE SOCKET..." is a problem for Chrome.

Comment 14 by Deleted ...@, Mar 13 2014

Tell me how to verify the issue.  What information do you guys need to fix this?

Comment 15 by Deleted ...@, Mar 13 2014

Attached are logs from a customer's environment, running Chrome v33 on a Mac. They grabbed a har and debug logs. The percentage of individuals experiencing this problem is low, but multiple individuals in their environment *are* experiencing the issue.
rechrometroubleshooting.zip
79.4 KB Download
Cc: eso-chrome@chromium.org
Labels: Hotlist-Enterprise
@11 you're seeing the fallout from  issue #313058 . The two may be connected, and in either case is near to rendering Chrome (and only Chrome) on that machine unusable.

Comment 18 by Deleted ...@, Apr 14 2014

I had this problem today, and "fixed" it by opening chrome://net-internals/#sockets and using the "Flush socket pools" button.  It immediately started working again.  We'll see how long it goes, but for now it seems fixed.
 

Comment 19 by Deleted ...@, Apr 26 2014

I was having this problem of "waiting for available sockets" pretty much only with respect to a search on google.com, bing/yahoo searches were fine, msmit's solution worked instantly for me. This might sound strange, but the problem started when I saw a comment somewhere that said something like, "What happens when you type ooooo in google?". I stupidly did that and then google would hang until the solution above. Is that just a coincidence or was that something malicious? 

Comment 20 by Deleted ...@, May 2 2014

Not sure if this is related.  I am experiencing the same issue; however, it occurs with my browser after I have opened Chrome and left idle for a minute or two.  I actually may only have one page open and then attempt to do another search within the same window.  Adding another tab does not fix the issue.  Only closing and re-opening will correct the issue in my case.
Labels: Hotlist-ConOps
Hello,

There are several users in the forum reporting this issue with most recent reports from this week: https://productforums.google.com/forum/#!topic/chrome/E_g0Z_ke5do

Is there an update or would you like me to request additional information or net-internals logs?

Thanks!
Sarah

Happening all the time, with only 1 window open on google.com
Tried to flushing sockets. Looks like Google is losing it's mojo and good engineers.

Anyone even testing stuff before releasing it anymore?
I leave chrome open 24x7, hoping that's not issue because closing it should not be the answer.

Comment 24 by teakh...@gmail.com, May 16 2014

Seems to only affect Google - related sites for me.  Still have not discovered a solution.
I had luck flushing the socket pool, and in the three weeks since I haven't seen the problem resurface. 
Labels: -Type-Bug Type-Bug-Regression
Status: Untriaged
Could someone attach another net-log?

I'm marking this as a regression and setting as Untriaged due to multiple reports.
The request for another net-log (how? see: http://dev.chromium.org/for-testers/providing-network-details ) is because the previous log was inconclusive.

Comment 28 by Deleted ...@, May 16 2014

I had the socket issue, and also my pc freezing up when chrome was open. First time I've had trouble with it for a long time. A week ago I switched to firefox and may never go back!!

Comment 29 by vletr...@gmail.com, May 16 2014

Similar issue here since a few days... Here is a log from my Chrome
net-internals-log.json
1.2 MB Download

Comment 30 by vletr...@gmail.com, May 16 2014

And FYI, I did fix also the issue with the tip reported above: Flush sockets via chrome://net-internals/#sockets 
I too have had this for a few weeks now. Only happens when doing a Google search. IE always works right away if I just go past the exact same search. If I close Chrome while its trying to search and then reopen, it will get the results immediately. Then a new search will usually bomb. If I reboot then It works for a little while and then stops again.

PLEASE FIX!

Comment 32 by rfe...@gmail.com, May 18 2014

Having the same problem for over a week now. I believe it initially started following a Windows update. My O/S is Windows 7. I will try the fix and see if that works.

Comment 33 by Deleted ...@, May 19 2014

It's not the OS. I'm seeing the same socket problem with the latest publicly available version of Chrome on Mac OS X 10.9.2

If you need to see an example, visit http://sullivan.iolani.org/ with Chrome and try and play any of the videos towards the bottom of the home page. None of them will play and if you use the inspector and look at the network requests, all of the requests for the images and videos related to those players are stuck with a "pending" status. While that tab was open, I copied the URL of one of the video files it was trying to load and pasted it into a new tab and I receive the "Waiting for socket..." message in the status bar. It never loads until I close the original tab with the aforementioned homepage in it and then the video will load INSTANTLY in the other tab.

Chrome, you are quickly becoming the new IE. Get your house in order.

Comment 34 by vletr...@gmail.com, May 19 2014

The same file (1.2Gb) to be downloaded with my premium account: >1 hour announced with chrome (and no visible progress) vs only ~5 minutes to get that file with IE ?!

I am on the same PC, same most recent Windows 8.1 x64 updates, same network (LAN), same provider, same file, at the same time...

Also, I have disabled all the extensions within Chrome.

I cannot get it ?!

Comment 35 by wtc@chromium.org, May 19 2014

Labels: M-37
Owner: asanka@chromium.org
Status: Assigned
Asanka: assigned the bug to you because you're on the bug triage rotation
this week. (You're already investigating the bug.)

Comment 36 by Deleted ...@, May 20 2014

Version 34.0.1847.137 m

Comment 37 by pzai...@gmail.com, May 21 2014

Version 35.0.1916.114 m

Comment 38 by d...@mail.ru, May 21 2014

So what was the problem?

Comment 39 Deleted

Comment 40 by pzai...@gmail.com, May 21 2014

One thing I did notice in the screenshot above, is that they have lastpass installed as an extension.  Troubleshooting some of our internal applications, I noticed that lastpass throws a lot of errors in the DOM.  I've disabled lastpass and haven't had the problem since,  will respond if this is just a temporary fix. 

Comment 41 by gary...@gmail.com, May 21 2014

FYI - I don't have lastpass installed and it's happening to me.
Interesting observation. I do have LastPass installed and am occasionally
seeing this problem, although not with enough regularity to tell if
disabling LastPass (which I really don't want to do!) would resolve it.

Comment 43 by vletr...@gmail.com, May 21 2014

FYI, I just uninstalled Chrome (keeping the browsing data) and did install the latest version. So far, I don't have the problem anymore when "searching" via the address bar. If I don't post here anymore, it means that the problem doesn't come back in the coming days.

Notice: I had no such issue neither on my other PC nor at work.

Cc: jgraettinger@chromium.org pauljensen@chromium.org
+jgraettinger and pauljensen:

Thanks for the logs everyone!

One possibility that jgraettinger brought up is that on an IP address change, SPDY sessions would be made unavailable without closing them. The assumption in the code seems to be that OS_WIN, OS_ANDROID and OS_IOS will terminate relevant TCP connections and thus would close the corresponding sessions as well. Therefore making the session unavailable would be sufficient (https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_session_pool.cc&rcl=1400145541&l=275).

However, it's possible that the IP address change notification doesn't concern the interface used by the SPDY session. Or it's possible that there are no active streams. This could, in theory, leave the socket in use with no way of it being able to close unless the user closes the sockets forcefully via net-internals.

I made the change to make SPDY sessions unavailable upon network change in r249349 in February but this bug was opened in December so I'm not sure the two are related.  Active sockets used for HTTP (non-SPDY) are however left open upon network change (only idle ones are closed).

I'm not sure I really understand how ClientSocketPoolBaseHelper::GetLoadState() determines LOAD_STATE_WAITING_FOR_AVAILABLE_SOCKET.

I'm interested to determine the root cause of frequent network changes being detected.  If this is detected on Windows running the attached netchange.bat and if it exits, uploading the resulting old_state.txt and new_state.txt files may help.
netchange.bat
165 bytes View Download
A problem with r249349, which I didn't understand well enough back in Feb (sorry!), is that the SpdySession::MakeUnavailable() call will only ever transition the session to closed if there's an active stream going over it, or if a FIN is read. I think we want SpdySessionPool::OnIPAddressChanged() to instead pretend that a GOAWAY has been received, and call session->OnGoAway(kHighestStreamID, GOAWAY_NO_ERROR). This effectively does:

session->MakeUnavailable();
session->StartGoingAway(kHighestStreamID, ERR_ABORTED);  // No active streams are affected (all have ID < kHighestStreamID), but pending and created streams are aborted (and retried).
session->MaybeFinishGoingAway();  // Closes the session iff no active streams remain. Otherwise, the session will close when the last active stream completes.

This isn't a complete theory for the reports in this issue, but it appeared to be a contributing factor in at least one of the net-logs I looked at.
Hehe that's what I proposed in patch set #1 of r249349 :)
This should be fairly easy to reproduce if our hypotheses are correct:  Just create some SPDY sessions, force an IP address change, repeat until this error is hit.
FYI some hints on forcing IP address changes:
On Windows just disable and enable Wifi or your Ethernet adapter.
On Linux you can ifup/ifdown eth0 (just be warned on Goobuntu this will be a bad time because you'll get locked out of your machine and not able to login...) or you can plug in a phone and enable/disable USB tethering (which creates an host interface with an IP address).

Comment 48 by d...@mail.ru, May 25 2014

Guys that is what I wrote in my comment #5 here. Waiting TCP connection is not closed when actual physical connection is missing. This is happening much frequently on mobile phones. Glitches in connection packet loss and so on leading to hang of connection. Chrome is waiting for data while server is already missed it and closed the connection. Sometime mobile operator even change a nat gateway for a client when he moves between mobile cells. Chrom should send keepalives more frequently. The default TCP keepalive interval is 45 seconds. This is completely unacceptable!
I have been experiencing this bugs many times a day for a long while. Usually I would be fine the first hours of the day, but then it hits. Only manually closing the sockets on chrome://net-internals/#sockets would fix it - and only for a few minutes, then it comes back. Incognito mode is always fine. Disabling and enabling the wifi adapter like suggested does not solve the problem. The bug seems to happen without any change of IP address.

Thanks to all developers trying to find a solution!
have been facing this hair-pullin problem for weeks on 2 home machines running on both win7 and 8. Tried the chrome://net-internals/#sockets flush socket thingy but it still comes back and haunt us. also Tried new pair of USB wifi dongle - doesn't seems to solved the problem.

Please find a solution quick, what a pity if we have to move away from the best browser in the world!

Comment 51 by Deleted ...@, Jun 5 2014

I have had this problem in the past and tried to replicate as I built a new win 7 desktop. All was fine until I installed VMWare Workstation, then the socket problem started. I uninstalled VMWare and all is good again. I need VMWare for development more than I need Chrome. 

Comment 52 by Deleted ...@, Jun 5 2014

Dear Google,

I have had this problem for a year and a half now. I have tried exactly 13 different fixes. They are all either temporary or do not fix the problem. Google as a company has clearly chosen to ignore this socket issue.

The response from Google corporation has been entirely inadequate and personally disappointing. Telling people every couple months that you fixed it in the update or are fixing it is dishonest and sharply lowers my opinion of Google as a corporation. Even worse is that every competitor out there has this problem fixed. I have used Chrome since the Beta invite but am uninstalling it today and switching permanently to Internet Explorer or Mozilla Firefox.

I will be telling every person I know not to use Chrome and will be changing my professional internet search recommendations. As the resident tech guru at home and the company I work, this will not be difficult. I even made sure to convince 4 friends already to make the switch before typing this. Next on the list is my family, and extended family, followed by my work. I was the one who convinced them to take up chrome and I can convince them to drop it. Google is displaying a poor understanding of how much supplier power it has in the search engine market and what that supplier power is built on.

When you ignore a problem for too long, and are continually dishonest towards hardworking Americans like me, we take it personally. And Microsoft stock goes up.

Thank You.
I experience this on both Windows 7 and Mac OS X 10.9.3

Windows version is: 35.0.1916.114 m
Mac version is: 34.0.1847.131

I open a lot of tabs at a time - easily close to 100, but only recently started seeing this issue.

I've been seeing this problem reliably now, with the Zappos site.  I can reproduce the issue nearly any time I want.  Is there anything that I can provide which would speed the resolution of this issue?
Google Chrome: 35.0.1916.114 m
Windows 8.1 Pro x64 Update 1

I am having this issue, and it is only affecting Google websites. The most heavily affected one is Google Search. YouTube is 2nd and Google+ is third. I don't seem to have much of a problem with Drive or Calendar. This is only in Chrome, not IE, Firefox, or Opera.

When multiple pages are "Wating for available socket" they will all fail at the same time. This has been happening since I did a fresh install of Windows a week ago. Chrome was the first thing I installed, and it has been consistant with the issue. 
Since my last post on May 17th it has went away for me. Not sure exactly when and nothing new or different has happened. No windows updates or anything unless Chrome updated during then and I am not aware of it.

Comment 56 by Deleted ...@, Jun 6 2014

I just used bing.com to search re: this issue. Get the picture?
Project Member

Comment 57 by bugdroid1@chromium.org, Jun 7 2014

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

commit 8952cde218e3bf28672382d2a920e2db5ecbedc2
Author: jgraettinger@chromium.org <jgraettinger@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Sat Jun 07 00:18:47 2014

SpdySession go-away on network change

In addition to making sessions unavailable, also
abort inactive streams and close idle sessions.

BUG= 324653 

Review URL: https://codereview.chromium.org/321513002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275570 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 58 by bugdroid1@chromium.org, Jun 7 2014

------------------------------------------------------------------
r275570 | jgraettinger@chromium.org | 2014-06-07T00:18:47.205291Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.cc?r1=275570&r2=275569&pathrev=275570
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.h?r1=275570&r2=275569&pathrev=275570
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_pool_unittest.cc?r1=275570&r2=275569&pathrev=275570
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_pool.cc?r1=275570&r2=275569&pathrev=275570

SpdySession go-away on network change

In addition to making sessions unavailable, also
abort inactive streams and close idle sessions.

BUG= 324653 

Review URL: https://codereview.chromium.org/321513002
-----------------------------------------------------------------

Comment 59 by Deleted ...@, Jun 7 2014

I used TOR for google shortly before my chrome stopped working with google, but ive done it a million times before.  

Still it's kinda funny...chrome...made by google...fails to connect to google and I had to use yahoo search to get here...

 Im not going to try anything else, ill give Bing a chance, it's the only other one with a nice layout.... habit is hard to drop but once I pick up a new one it may be too late...hope it gets fixed soon, over 10 years using google, my loyalty is two-sided, not mindless...so FIX THIS (im only a bit angry seeing the other comments, the issues has been around since april even if not for me, mine started today)
Step 1) Fix  google problem
step 2) THEN build a damn self driving car
Would an enterprising soul who is regularly seeing this problem be willing to try the Chrome Canary channel, and report back as to the outcome? Thanks

In my own testing, I see that sockets are now reliably reclaimed in Canary when I toggle the network interface, where they're not on Stable.
Owner: jgraettinger@chromium.org

Comment 62 by kris...@gmail.com, Jun 9 2014

I just tried Chrome Canary (for about 10 minutes), and I can report that the coalmine now appears to be safe.  The so-called "stable version" goes kaboom the moment I open Google Calendar. Subsequently all web apps on *.google.com become inaccessible (the dreaded "waiting for socket" issue). 

These problems didn't occur in the Canary version.  Can't wait for the changes to be propagated to the stable version, so I can switch back to Chrome fulltime from Firefox.

I disagree -- I still have the issue with "Waiting for available sockets". 

I verified that the problem would replicated using Mac OS X 10.9.3 and Chrome 35.0.1916.69 beta
Then I downloaded and installed Chrome 37.0.2039.0 canary into a different location, fired it up, loaded up the same set of tabs -- and I still get "Waiting for available sockets" on the same pages.

So it doesn't appear fixed to me.
Version 35.0.1916.153 m
Windows 8.1

All Google Products (Search, Apps, Mail, Calendar, Voice, YouTube) say searching for socket for a while and then go to a screen that says Network Unavailable. All other websites work just fine.

Firefox works fine, haven't tried other browsers.


Comment 65 by Deleted ...@, Jun 19 2014

Echoing #64 above me. 
Win 8.1
Chrome 35.0.1916.153 m

Google sites only as far as I can see.  Haven't had an issue with any others.  going to  chrome://net-internals/#sockets and closing idle sockets works, but that seems crazy to have to do that. 

Comment 66 by Deleted ...@, Jun 23 2014

I noticed this only happens when I am using my (very flaky) company VPN, so I guess windows is telling Chrome every 1-2 minutes that the network landscape has changed.

Comment 67 by mst...@gmail.com, Jun 26 2014

Version 35.0.1916.153 m
Windows 7 Pro (all updates)

Intermittent, but often, with Google product sites only.  Most often occurs when searching directly in the address bar.  The chrome://net-internals/#sockets trick works, but only very briefly.

It doesn't happen in other browsers.  It doesn't happen in incognito.  It happens on different wifi networks.  I've rebooted/relaunched/gotten rid of extensions, etc.  Mainly I use Firefox now, but keep hoping this will get fixed.

Comment 68 by Deleted ...@, Jul 14 2014

I have the same problem. It occurs inconsistently but frequently. I am writing this using IE. Chrome version 35.0.1916.153 m.

Comment 69 by Deleted ...@, Jul 14 2014

Not happening now.  No idea why it stopped.  Possibly network related?

Comment 70 by Deleted ...@, Jul 14 2014

I am getting this every day now using 35.0.1916.153 m, Win7 x64.  Chrome has become almost unusable for google sites.
The expected fix (landed in comment #58) is being deployed with Chrome version 36 very soon. I'm leaving this issue open to see if reports die down at that point. Cheers,

Comment 72 by pgjen...@gmail.com, Jul 15 2014

Okay, I updated to 36.0.1985.103 beta-m, but I'm guessing it just hasn't been merged into the beta branch yet, and that's what's coming very soon?  I had to wait on a socket to load this page :)
Version 36.0.1985.103 (Official build 280322) m
Windows 8.1 64-bit

Please fix this issue AS SOON AS POSSIBLE, because I depend on many Chrome apps. Using the canary channel of Chrome leaves me with those apps I depend on crashing all the time, while the beta channel of Chrome has the same issue.

I'm starting to regret I use Chrome, Drive and all productivity apps which depend on those. I am flushing the socket pools daily for weeks now, too many times a day.
Still happens in 37.0.2062.20 beta (OS X build).
This is getting so annoying. Flushing sockets so many times a day...
For those still who can still reproduce this with versions 36 and above, please provide a net-log to allow us to investigate. The log capture should begin prior to the "Waiting for available sockets" condition appearing, and can end once it's been seen. Thanks

See: http://dev.chromium.org/for-testers/providing-network-details

Comment 76 by Deleted ...@, Jul 24 2014

Chrome Version 36.0.1985.125 m
Waiting for sockets appears after opening and closing roughly 10 Google websites
See attached Log
net-internals-log-140724.zip
1.3 MB Download
Thanks Chad! The log shows the same known issue, which led me to discover that I'm a bit of a bonehead and misread when the change in #58 is landing on stable. It's currently on Beta (M37), and not stable (M36).

pgjensen and/or chadbalser, could you confirm whether the issue resolves on current Beta M37? If so, I'll request a merge to M36.

Comment 78 by Deleted ...@, Jul 24 2014

I cannot reproduce on M37!
Labels: Merge-Requested
Requesting a merge of r275570 to M36 (branch 1985). r275570 has been on M37 since branch cut.

This fixes a regression which consistently impacts a smaller number of people.
Cc: matthewyuan@chromium.org
Labels: -M-37 M-36
Adding the appropriate milestone and CC'ing the M36 TPM.  Removing M-37 milestone (as it's already fixed there, per #79 - though you may want to take a look at #74...).
Thanks. The regression (and fix) in #58 are platform-specific (Windows & mobile) and didn't present on OS X.

#74 is likely something else. mike@sheridan-net.us and stefan.kronawithleitner, if you can reproduce a "waiting for socket" on OS X under M37, please post a net-log.
Have reproduced in Mac OS X w/ Version 37.0.2062.44 beta
Will go back and get a net-log and post shortly.
net-internals log for reproduced condition on Mac OS X as requested.

net-internals-log.json.zip
937 KB Download
@mike.sheridan: This looks like expected behavior to me. Chrome maintains a socket pool which allows no more than 6 connections to any origin (regardless of the number of tabs open).

Connections to Zappos here are over HTTP/1.1 (not SPDY), which means that a socket can load only one resource at a time, and in this logs's case those sockets are all being used for streaming of long-lived and stalled media files (possibly because players are paused in backgrounded tabs?). I'd also recommend disabling all extensions and seeing if the problem persists.
I have the same issue. Incognito works without fail for me. Strangely, disabling all my extensions does not help the problem.
I'm experiencing a "Waiting for available socket" issue in 36 and 37 on OS
X 10.9.4.
I can reproduce it every time with the Teamcity server.

To reproduce:

1. Open http://teamcity.jetbrains.com/?guest=1
2. Open http://teamcity.jetbrains.com/changes.html?guest=1 in a different
tab
3. The first tab produces something like 50 pending connections (in the
chrome://net-internals/#sockets)
4. The second tab is now showing "Waiting for available socket"

This might be "correct" behaviour in terms of waiting for sockets, since
there are many connections pending. However, there's something definitely
wrong here since it works as expected on every other browser.

Comment 87 by fi...@mxd.cz, Jul 27 2014

Same experience on Chrome Version 38.0.2101.0 dev (64-bit), Ubuntu 14.04

Comment 88 by fi...@mxd.cz, Jul 27 2014

BTW it happened to me several times when clicking an SSL link to a Twitter page from TweetDeck app (a new tab opened, waiting for a socket..., working when TweetDeck is closed :)
Labels: -Merge-Requested Merge-Rejected
Rejected, fix seems pretty big so we should punt this to 37.
Similar occurs with me on MacOSX on a couple hostmonster.com-hosted sites.
Version 36.0.1985.125
Occurs mostly upon reference from another web page.
This occurs *even if* the same site is open in another tab, with address entered directly, just fine.
I only have this issue with one ISP - a local cell phone provider, whose network I access through a Franklin Wireless "Mi-Fi"-type device that connects my home network to the cell company's 3G via EVDO. If I tether to my actual cell phone (through one of the big national companies), or if I go to McDonald's or to my neighbor's house, I never see this error - only on this particular ISP.

If I run "netstat -n" from a command prompt while connected to this device, I get lots of "FIN_WAIT_2" statuses. As it turns out, this device is not forwarding the FIN/ACK packets correctly. 

Upthread someone mentioned that Chrome only uses a pool of 6 sockets; it's actually even worse than that - Chrome uses a technology called "socket preconnect" that attempts to predict what resource you're going to need next and initiates a connection with that server so that it's ready before the browser even sends a request. It's kind of like DNS prefetch, only it works with socket connections. In other words, these 6 sockets are almost always in use.

When the connection is flaky and the TCP 'FIN' packet isn't forwarded properly, the connection is held open by Chrome and it has to wait for a time out because it can't successfully close the connection. 

If you're having this error, check "netstat -n" from a command prompt and see if you have several connections are being held at FIN_WAIT_2. If that's the case, you might have a firewall issue - this could be your hardware firewall built in to your cable modem, the one on your wi-fi router, or you might have a 3rd party firewall installed on your computer. Try to temporarily disable it to see if the FIN packets start coming through and the TCP connections start closing - this may take care of the issue. Also, if you have a laptop, try a few different connections at other places to see if it is isolated to your home network.
Looking at mike.sheridan's log, it's a different issue from the SPDY problem that jgraettinger fixed.  The network stack is blocked on some external object that pauses but never resumes a request, so we need to figure out what that object is.  Once we get 6 sockets for a single domain in that state, we can never issue a request to that domain until Chrome is restarted.

mike.sheridan:  Mind filing a new bug with that file attached, and posting a link here?  I can do it myself, but I'd like a description of just when you're seeing that issue.

ox45tallboy:  Chrome use 6 sockets per domain/protocol/port triplet, not 6 connections total.  The global limit is something like 256 sockets, unless you're using a proxy, in which case it's 64, I believe.  It would be great if you could provide a net-internals dump as well.  (There's a link to instructions when you navigate to about:net-internals).
mmenke: "The network stack is blocked on some external object that pauses but never resumes a request, so we need to figure out what that object is.  Once we get 6 sockets for a single domain in that state, we can never issue a request to that domain until Chrome is restarted."

This seems to match what I was saying about the FIN/ACK packets never being received. It appears Chrome is limited in the number of sockets it will open simultaneously to the same server/domain, and it won't close one unless it gets the ACK and FIN packets it is expecting from the server. Chrome appears to leave the connection open until it times out and won't release it for a new request until a keepalive is overdue. 

I'd also like to note that in my experience, manually flushing the socket pool (chrome://net-internals/#sockets) rather than restarting Chrome completely will also allow new requests to a domain that is currently unavailable due to sockets in use. I've also had luck with "waiting it out" until the timeout expires.

I must have done a poor job of explaining what I meant above regarding the 6 sockets almost always in use. It's my understanding that the sockets are opened when the web page is first read the same way that DNS is prefetched; this way, multiple items can be downloaded simultaneously from the same server (images, etc.) and the connections are ready before the browser even makes the actual request for the object. With multiple items being downloaded, multiple connections to the host will be opened before they are even needed. If these sockets don't close properly, Chrome won't send another request to that server/domain until at least one does - while in the meantime, other things like imbedded ads that come from a different server/domain will load just fine on the same page.

I'll have a net-internals dump up later tonight when I get home to that Internet connection. In the meantime, could someone else who is having this issue try looking for "FIN_WAIT_2" status messages resulting from a "netstat -n" at a command prompt? If they are there, run a reverse DNS on the IP in that state and see if matches the domain you were trying to access when you received the "Waiting for available socket" message. 
The issue isn't the sockets not closing properly - the issue is that the network stack gets requests, then starts reading data, and then something (Within Chrome, but outside the network stack) stops us from reading further from the requests, so they're effectively paused at some point after we start receiving data.

I'm rather surprised that clearing the socket pool seems to work - in this paused state, the socket pool doesn't own, or even have references, to the sockets, as they're owned by the paused transactions, so it can't even close them.

You're basically right about preconnect, though it only connects as many sockets as it estimates were needed last time you visited the site.  I was misunderstanding you - I thought you were saying it was a global (Not per-domain) limit of 6, and with all the preconnecting, we were effectively always at our global socket cap.
What I meant was that with all the stuff being downloaded on a modern 
web page, we're quite often at our cap for that domain as soon as the 
page starts loading. If you click on a link to a different page on the 
same domain, you're limited to the number that successfully closed after 
the first page was loaded, and each successive page load from the same 
domain makes it more likely that more sockets will not be closed 
properly. If you're browsing slowly, some of these connections will 
transparently close due to timeouts; lots of page loads make sockets 
closing due to timeouts less likely and it will be more likely that you 
will begin to see the "waiting for available socket" errors.

Can we at least consider that the TCP connections initiated by the 
browser might not be closing due to the fact that the FIN/ACK packets 
are not being received, and that this would account for the "pausing" 
that you're seeing - what if ordinarily, the socket would have closed 
and re-opened at the new request rather than remained open for a second 
request (even though it's for the same domain/server). It would make 
sense to attempt to close every socket as soon as one request was 
fulfilled because Chrome is coded for socket preconnect and the coder 
would want those sockets ready for the next connection.

In essence, what might appear to be a connection open to the server 
might actually be the previous connection to the same server hung in a 
wait state, and the request is held up waiting for *its* connection 
because the FIN packet on the connection that is up has already been 
sent from the client - the network stacks won't send anything else after 
the FIN packet except the ACK once the server's FIN is received.
mike.sheridan's net-internals dump clearly shows the situation I described.  I have yet to see one from you.  It's entirely possible you're encountering another issue.
Oh, and we generally reuse sockets for multiple requests, so we keep them open after use.  Generally if the server thinks the socket is closed, and we don't, the server should send us an RST when we try to reuse the socket, and then we retry.

Some buggy NAT routers may timeout sockets quickly and then blackhole attempts to use the sockets, rather than returning RSTs.
I see this regularly--and not with other browsers--on pages that have multiple audio streams (audio tags with sources, but not playing). Chrome appears to queue up 6, and the others have no metadata read, and can't be played.

This is surely related to the discussion today.
Labels: Restrict-AddIssueComment-EditIssue
M.I.Schwartz23, ox45tallboy:  Could one (Or preferably, both) of you collect about:net-internals dumps (Link to instructions on that page) of this happening, file new bugs, and email me the bug IDs?  I'll take a look and figure out if they're the same issue.

I'm closing this bug to comments, since a bug with 100 comments and covering multiple issues just does not work well.
Status: Fixed
Marking this as fixed.  The original SPDY issue was fixed, and is completely unrelated to ox45tallboy's and M.I.Schwartz23's issues.

M.I.Schwartz23 has filed a new bug as  issue 401845 , which looks to be an issue with the media player code leaving a bunch of paused requests hanging around.

Sign in to add a comment