Closed Bug 91429 Opened 23 years ago Closed 23 years ago

Intermittent "connection refused" errors [@ nsHttpHandler::GetConnection_Locked]

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: kaufman, Assigned: badami)

References

(
URL
)

Details

(Keywords: crash, helpwanted, topcrash, Whiteboard: [patch needs r/sr=])

Crash Data

Attachments

(4 files, 3 obsolete files)

Java errors from Augustus's comments. May be unrelated.
10.13 KB, text/plain
Details
remove oldest connection if max connections exceeded when a new one is created.
1.05 KB, patch
Details | Diff | Splinter Review
really incorpoarting bbaets's comments
827 bytes, patch
bbaetz
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
use RemoveElementAt instead of RemoveElement
1.55 KB, patch
bbaetz
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review 
I'm getting this message popup on probably ~10% on the links I click on.

"The connection was refused when attempting to contact <some web site>"

Reclicking on the link might get me through or it might popup the same message
(sometimes several times).

This has happened on all sorts of sites such as google and slashdot.

This has been happening for all the nightlies I have downloaded in the past
month (at least).

In reading some of the other bug reports in trying to find a cause (or progress
in fixing), perhaps a proxy problem at my ISP (alltel) is the problem? (I don't
run a proxy) Another reason, I've seen a similar occurrence with Netscape 4.x

-mike

PS: though I don't use it often, I have not seen this problem on Win98 using
Netscape 4.x or IE
-> Networking

Is it possible the ISP is running a SOCKS proxy upstream?  That would make this
a likely dup of bug 48357.
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc
Do you have ipchains or some sort of packet filtering program running that might
refuse certain sites?  If you do not see the problem on W32 then it most likely
is not an ISP issue (this of course assumes that you use the same ISP for both
Linux and W32).

I got that problem on Win98 while running Norton Internet Security (firewall). 
Come to think of it, I don't believe I recieved that with NS 4 or IE 5.5 while
on Win32 either.. only on Mozilla... this could be a bug if it's not a dupe.
I have noticed this specially with pop mail
I think this is a bug because sometimes when i receive the connection refused
dialog, when i click it again it pop ups the same window again, so fast i know
mozilla could not have done a retry already
The main Alltel help desk said as a rule, Alltel doesn't run proxies, but he's
obviously not a tech. I'll call the Kansas Alltel desk tomorrow and see what
they have to say.

I don't run ipchains and no packet filtering. It's straight ppp.

20 minutes of random browsing on Communicator 4.75 (win98, different box, same
ISP) yielded _no_ connection problems.

If there is no obvious Proxy, lets assume there isn't one.

In the past, many people have turned off HTTP 1.0 or Keep-Alive (Persistent
Connections) as a troubleshooting method...
Kansas Alltel says `NO proxies here`.

---------------
>In the past, many people have turned off HTTP 1.0 or Keep-Alive (Persistent
>Connections) as a troubleshooting method...

I did this, nothing changed. If someone would like to email me as to how exactly
to go about doing some diagnostics, that would be nice, (newbie bug hunter) 

need some help getting a test case here.  I have not seeing this either behind a
firewall at netscape nor at my home using pacbell DSL.
Assignee: neeti → gagan
Target Milestone: --- → mozilla0.9.3
I use a 256k/64k adsl connection behind a linksys router and really the only one
url that showed this problem for me was the ftp slackware page
->helpwanted

I would advise a higher milestone. There are lots of bugs more important
Keywords: helpwanted
->darin
Assignee: gagan → darin
unlikely to be the same SOCKS problem, unless specifically indicated.
I dont use socks
I use an ADSL modem under a linksys router
Who knows if bug 84580 and bug 92195 are related...
i have seen this quite a few times from home using an ISDN line.  it is
typically associated with the first attempt i make to connect to a website, and
i've always just assumed it was related to my ISP.  i'll take a closer look at
this when i get chance.
-> moz0.9.4
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → mozilla0.9.4
If you ever see this in mail, go to mail and hit "get mail"
You should get instantly a connection refused error
That's why i think it's not isp related but mozilla related
One way to get "Connection Refused" error:

1. Add "127.0.0.1   ad.uk.doubleclick.net" to /etc/hosts
2. Go to http://www.theregister.co.uk
3. Notice error.

Can we suppress the error in prefs?
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsWebShell.cpp#1049
(thanks Chris Hiner)
Nevermind, above comment a separate issue:
http://bugzilla.mozilla.org/show_bug.cgi?id=28586
Priority: -- → P4
Target Milestone: mozilla0.9.4 → mozilla1.0
Ok, this bug looks very similar to behavior that I'm seeing.  Before I say much,
here's my string from "About Mozilla" : Mozilla 0.9.3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3) Gecko/20010801.  I'm using a
56K dialup through Earthlink.  And for the record, my Windows 98 is SE and I've
got IE 5.00 (the default one with 98SE).  The behavior that I observe:
occasionaly, when I try to go to a website, either by typing the URL in directly
or by clicking a link, I get the aforementioned error dialog: "The connection
was refused when attempting to contact <website>."  I have not yet found any
patterns in when this pops up, however, in contrast with Mike's experience, I
have never observed actually getting through to the site if I keep retrying. 
Even retrying many hours later does not change anything.  I also notice that a
Java Console icon has shown up on my system tray (I think that's what it's
called).  I have no idea if it's related, but...  Opening it, I see many Java
errors, although to my knowledge none of the pages I tried to open had any Java
on them.  Also, the console window is rather broken: it doesn't update properly
as I scroll.  I do have Sun's new Beta Java JRE installed, but I'm hard pressed
to guess any correlation.  I'm going to attach the errors from my Java console
in case they provide a hint.  If you have any specific questions, feel free to
email me, and I'll continue to watch for patterns or other seemingly correlated
symptoms.  Oh yeah, and the pages load just find in my IE 5.  I can go to IE,
load the page, and switch back to moz and have it fail again, so I'm rather
confident that it's a moz specific issue.  The behaviour is sporadic but has
happened enough times that I've developed a work around--open it in IE :( Thanks-

Augustus Saunders
I dont think java has got anything to do with the initial connection to a
webpage, but thanks for the report.

In my case, i get this mostly in mail. Retrying, not once or twice but a LOT of
times (like 10) gets my mail downloaded. Of course, downloading lots of stuff in
my connection makes this problem appear more since i have less bandwidth
available, and mozilla mail timers are really sensitive

Why can we configure the timeouts mozilla uses for mail?
i suspect this is bug 92675... please try that patch and let me know if it
improves things.
a=asa on behalf of drivers
I get a 'The connection was refused when attempting to contact
us.f132.mail.yahoo.com' message without fail every time I log into yahoo mail
using a 0.9.3+ build.  The problem is NOT present in 0.9.3 itself.

Other random connection refused messages come up when accessing message boards
on bbs.play.net and when following links on any site.  (even when initally
loading the mozilla.org homepage.)  Usually the page appears after pressing the
'ok' button on the error dialog, but in framesets sometimes only one frame will
load.  (such is the case with mail.yahoo.com)

I've been checking to see if this had been fixed for a few weeks now, but since
it hasn't in today's build (2001090808), I figured I'd add my experiences..

Have a great day!

Scott

(oh, and I'm posting this with 0.9.3 because there's some problem with today's
build that won't let me post...)
Oh, and I'm running windows ME, so I'd guess it isn't just a linux problem.

scott
After moving to another state and another "ISP" (university modem pool)
I have seen _zero_ "connection refused" errors. It could be that this 20010922
build that I am using fixed the problem, but I imagine that this is not purely a
mozilla problem. Now why mozilla doesn't play nice in whatever situation that
was, and a windows browser does is another question.

If anyone wants more precise details of the circumstances which I was in, let me
know.I can also supply the phone number to the old ISP.

Again, Alltel Kansas says they run no proxies, but the guy I talked to could
merely be ignorant of reality.
-mike
Yes, things are *much* better this week.  I use Mozilla a lot at work...  often
all-day long, and the browser was becoming unusable for a while for me due to
connection-refused errors.  Yesterday I got a little excited because I realized
I hadn't had any of these errors, and then I had one.  But it was the only one
all day.

I wish I could figure out some sort of specific pattern to these, but can't. 
One thing that I noticed, however, is that the error happened much more
frequently if a URL had been typed in or if teh page had been spawned from Outlook.

Using Win 98 with a proxy.   
it may be worthwhile to just increase the connection timeout from 30 seconds to
a minute (or more).

bbaetz, gagan: what do you think?
30 seconds should be high enough, shouldn't it, unless the website/your link is
very congested.
actually, i used to see this error when first connecting via ISDN... my ISDN
router would have to dialup before the connection could be established, and this
would often take on the order of 30 seconds to complete.  the result would
almost always be that the page i initially loaded would fail with "connection
refused"

this was especially bad due to a bug in http that would still try to reuse these
connections in the future... always failing to load, and never pruning away the
bad connections!  that bug has been fixed for a while now, and makes this bug
less severe for sure.

however, i still think there would be some value in increasing the connection
timeout... afterall, it couldn't hurt.
Oh, so you're using demand dialing? Yes, that would explain it.

However, it is an edge case. What timeout did ns4 use?
I'm getting this message popup on all address that I try to connect to, and 
the message comes up instantly.

I'm using Mozilla 0.9.6, on Windows XP Professional.

When using Internet Explorer, I have no problems. This combined with the fact 
that the connection refused message comes up instantly leads me to believe 
that this is a bug with Mozilla and not my setup.
philip: how are you connected to the internet?  via a proxy server perhaps?
Darin, you asking if I was using a proxy server got me thinking. Although I
don't use a proxy server, I used to use Zonealarm, a firewall. However, I had
removed it from my startup folder some time before installing Mozilla. Upon
closer inspection, I found that the Zonealarm services were still loading up,
and blocking Mozilla's internet access, yet as I had stopped loading the main
program, I wasn't getting a message from Zonealarm.

So, in the end the problem wasn't a bug in Mozilla, and thank you for your help.

Philip
In my case, I am getting these errors at work on a Win98 box, and we do have a
proxy server.  However, the problem is with Mozilla because I can simply
cut-and-paste the problem URL into my IE5.0 window and I'm fine.

I'm not noticing this problem anymore at home on a 56K modem with no proxy server.

The most unpredictable thing is that sometimes a URL that is working just fine
in Mozilla will give a connection refused error when I attempt to reload it
after a certain absence.  After a previously-working URL gets its first
connection-refused status, it seems that it can't be connected to again unless I
shut down the browser and restart it.
kevin:

have you tried configuring mozilla to use HTTP/1.0 and/or disabling keep-alives?

look in Edit->Preferences->Debug->Networking

some proxy servers do not implement HTTP/1.1 correctly (or even HTTP/1.0
correctly  w.r.t. keep-alive connections).
Data point: I've seen this too. I'm behind a transparent proxy - ie I don't set
anything in the proxy fields.

I get this about 2-3 times per week, though, but in all cases a reload does fix
it. Could be my ISP's servers acting up, though. This doesn't feel like a 1.0
compatabililty thing, but I could be wrong

darin: When do we pop up this dialog? Don't we retry a couple of times first, or
something?
we only retry, if after successfully connecting to a server, we read 0 bytes
(ie. EOF).  in this case we resend the request.  we don't do anything but report
the error if the connection fails.  there have been bugs in the past that caused
us to cache nsHttpConnection objects that never established a connection.  doing
so can lead to quick "connection refused" errors.  so perhaps there is another
race condition somewhere that could lead to such a state.
with no good way to repro this problem, i'm going to push this off the 1.0
radar.  that being said, it might still get some attention before 1.0, time
permitting.

-> future
Target Milestone: mozilla1.0 → Future
Just have to add my $.02, since this seems to have migrated from a Linux to
Win98 discussion.

After 'heavy' web surfing w/ Mozilla under win98, I sometimes get numerous 'The
connection was refused' messages, almost to the point where Mozilla has ceased
to be able to fetch any pages.  If I wait a while Mozilla starts working again.
 If I disable keepalive in Mozilla (I'm not using a proxy), I never have this
problem.  

If I do a 'netstat -s' right after I get a 'connection was refused', I see about
85 current TCP connections (Win98's max is supposedly 100).  If I set
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\MaxConnections to
200, I get current TCP connections up into the 130's but no 'connection refused'
messages.  It seems that (in some cases anyway) Mozilla is hitting a max TCP
connection ceiling and giving a 'connection was refused' message.  With
keepalive disabled in Mozilla I generally don't see more than a dozen current
TCP connections, so it seems to me that maybe keepalive is a little too
aggressive?  I sure don't see anywhere near this many established TCP
connections accumulating when browsing w/ IE6/NC4.79.  Hopefully this info is
relevent.
excellent information... thank you!!
Very interesting, i hope someone can tell me what is the limit connections in 
linux, and how to tweak it if possible
Interesting comment concerning the number of connections.  I was using a site
that started giving me "refused" messages, so I decided to wait it out.  Sure
enough, I was able to connect again after waiting a few minutes.  I normally
wouldn't wait so long of course, so I never noticed that such a site would be
come usable again.

Turning off keep-alive and setting HTTP to 1.0 didn't seem to help with
anything, unfortunately.

However, there is also something domain-related going on here in some cases.  At
work (Win 98, T-1, proxy server), if I go to
http://www.lynuxworks.com/products/bluecat/bluecatbsp.php3 and click on any of
the first three board-description links (to cirruslogic.com), I get connection
refused.  Maybe it doesn't like the onClick handler in some cases?   At home
(Win95, modem, no proxy), I connect just fine on these links.

Anything else I should try?
Kevin: is that a manual proxy or transparent proxy?
The occasional "connection was refused" message, where the same web site works
without noticable hesitation in other browsers, may be a manifestation of bug
#86917 - "socket transport should try all ip addresses returned by DNS service".

If a name server returns multiple IP addresses for a hostname and the first IP
in the list happens to be refusing connections or is outright dead, Mozilla will
not try the other IPs at its disposal, not even if the hostname is reentered or
Reload is clicked.  Not even if Mozilla is exited and restarted.  Not even if
Mozilla is killed in the system tray and restarted.  The OS'es DNS cache has to
be flushed and Mozilla restarted, and even that doesn't guarantee that you won't
get the IP list in the same order as before.  Target milestone for bug #86917 is
1.0.1.

rcummins: i agree with you... fixing bug 86917 is sure to help this bug.
I was using a manual proxy connection (SOCKS v5) at work and that seems to have
been responsible for (at least some of) the "domain-related" errors I reported
yesterday.

I just changed the setting to "automatic proxy URL" and the problems I reported
here yesterday regarding
http://www.lynuxworks.com/products/bluecat/bluecatbsp.php3 seem to have stopped.
 I'll leave my browser set this way and let you know how it goes over the next
couple of days.
This problem has been bugging me for a long time, but as a retry would generally
work, I didn't worry about it too much. However, with Mozilla getting ever
closer to v1.0, I think it needs looking into.

I'm about to try the registry edit as mentioned in Comment #39 as I'm running
Win 98SE, and see if that fixes things. As this bug/problem is not overly
predictable, I'll report my results in a few days.
i think the problem here is that mozilla only limits the number of active
connections.  that does not include the numerous idle connections that can grow
in mozilla idle connection list.  what we really should be doing is limiting the
total number of connections.  if we start reaching this limit, then we need to
start pruning "old" idle connections.

-> mozilla 0.9.9
Priority: P4 → P3
Target Milestone: Future → mozilla0.9.9
Keywords: mozilla1.0
As a followup to my Comment #47, I can't find the MaxConnections registry item
anywhere under Windows 98SE, this may be due to my being on a Cable Modem
attached via an Ethernet NIC.

This would lead me to agree with Darin is his Comment #48. Another solution to
his example, would be to make the max connections configurable to suit ones
internet connection.
the plan is definitely to one day add connection settings to the preferences
dialog, which would definitely include a maximum value.
Re Comment #49

The MaxConnections value has to be added (you won't find it unless you've
already added it), see
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q158474


 Re #51, OK, now I have a MaxConnections entry....I'll report back after a
reboot and some testing.

Also, Re #50, that is good news. However, in the interim, would it possible to
up the current max value? If someone could give me some pointers to the right
file, I could have a go at doing it myself.
My MaxConnections is now set to 200, but I just got the infamous connection
refused message again. Mind you, I did have a lot of non-Mozilla TCP/IP activity
happening at the same time.

As the message seems to come up very quickly, when it does happen, I wonder if a
retry could be coded in, as that it what I do to get around the problem anyway.
-> 0.9.8 (perhaps)
Target Milestone: mozilla0.9.9 → mozilla0.9.8
not going to make it for 0.9.8  -->  let's try for 0.9.9

vinay: if your interested in working on a patch for this one, let me know.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Sure, let us discuss what u would like me test this thru. Are folks still seeing
this after the timer changes for pruning http keep-laive connections got added ?

Vinay, when did the timer changes land on daily builds?

The last time I saw the problem was with build 20020110 when my cable modem
service provider had some technical problems that was causing severe packet loss.
This landed quite a while ago. 20020110 would have certainly had it.

So have u run into this under normal operating conditions ?

 
I haven't seen it in the last few days under "normal" conditions.
vinay: despite the timer patch, this bug could still happen.  if the user visits
enough sites to collect enough live connections (in the idle state), we could
exceed the operating system's limit.  the bug in mozilla is the fact that we
only limit the number of live connections actively in use.  we don't limit the
number of total live, idle connections.
I'm going to revise my comments in #59 as I've changed my Operating System limit
as per #39 & #51. My system is no longer "normal" as it doesn't follow the
default Win 98 SE configuration.
-> badami
Assignee: darin → badami
Status: ASSIGNED → NEW
From Darin on AIM
the connection management code in nsHttpHandler, you'll see that we don't ever
enforce a maximum number of connections
we only enforce the maximum number of active connections
we should also enforce active+idle <= maximum
but it might mean killing off some idle connections when we reach that limit if
we have not already reached the active connection limit
Darin,
1. We can never to anything with the active connections since they r in use.
2. We can purge the idle connections whenever active + idle >= mac connections.
3. This can be done 
    a. In the PurgeDeadConnections
    b. And also whenever ReclaimConnection is being called.

U think this suffices ?

Vinay
vinay:

actually, i think you only need to purge idle connections in
GetConnection_Locked, if a new connection must be created.  there should be no
need to change ReclaimConnections or PurgeDeadConnections.  GetConnection_Locked
does the following:

1) check if we're at the active connection limit, if so abort
2) check if we can reuse an idle connection, if so use it
3) if no idle connection, then create new connection

at this 3rd step we need to enforce (active + idle <= max).  if we would exceed
the maximum by creating a new connection, then we must find an idle connection
to kill off.  i'd suggest removing the oldest idle connection, which should be
at the tail of mIdleConnections.  so, you'd only need to remove the last element
of mIdleConnections if (active + idle == max) before creating a new connection.
Comment on attachment 68497 [details] [diff] [review]
remove oldest connection if max connections exceeded when a new one is created.

Obsoleted by attachment (id=68497)
Attachment #68497 - Attachment is obsolete: true
Comment on attachment 68497 [details] [diff] [review]
remove oldest connection if max connections exceeded when a new one is created.

Correct patch; this obsoletes attachment (id=68302)
Attachment #68497 - Attachment is obsolete: false
Comment on attachment 68302 [details] [diff] [review]
purge old idle connections if we are >= maxConnections

This is obseleted by attachment (id=68497)
Attachment #68302 - Attachment is obsolete: true
Darin, Gagan, Bbaetz
Can u folks do a r/sr on this please ?

Vinay
Comment on attachment 68497 [details] [diff] [review]
remove oldest connection if max connections exceeded when a new one is created.

>Index: nsHttpHandler.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v
>retrieving revision 1.47
>diff -u -r1.47 nsHttpHandler.cpp
>--- nsHttpHandler.cpp	2002/01/27 06:02:39	1.47
>+++ nsHttpHandler.cpp	2002/02/08 03:39:45
>@@ -736,6 +736,17 @@
>             NS_RELEASE(conn);
>             return rv;
>         }
>+        
>+        // We created a new connection
>+        // If idle + active connections > max connections, then purge the oldest idle one.
>+        if (mIdleConnections.Count() + mActiveConnections.Count() > mMaxConnections) {
>+            NS_ASSERTION(mIdleConnections.Count() > 0, "idle connection list zero lenght");

You misspelled length.

>+            if (mIdleConnections.Count() > 0) {              

Theres lots of trailing space on this line, and you should use
!mIdleConnections.Empty()

>+                nsHttpConnection *conn = (nsHttpConnection *) mIdleConnections[0];
>+                mIdleConnections.RemoveElement(0);
>+                NS_RELEASE(conn);
>+            }

Why were we getting this error to begin with? If the user wants to create too
many connections,
shouldn't we do something better than pop up a "connection refused" error?
Attached patch incorporate bbaetz's comments (obsolete) — — Splinter Review 
1. Corrected spelling
2. No IsEmpty on nsVoidArray. No can do.
3. Removed white spaces.
4. We are restricting max connections by popping an idle one whenever the limit
is exceeded and a new one is created. Earlier we were not doing this.
bbaetz: windows 9x has a limit on the number of sockets.  apparently, when that
limit is reached, we get a NS_ERROR_CONNECTION_REFUSED.  it may actually be
another error code instead as i believe we munge error codes a bit in the socket
transport, but that's really besides the point.  we have user prefs to limit the
maximum number of http connections, and we currently aren't honoring that
preference.  this patch will solve that problem.  we may decide that the default
maximum number of connections is too small, but i doubt it.
Comment on attachment 68531 [details] [diff] [review]
incorporate bbaetz's comments

vinay: this seems like the patch for a different bug.
Attachment #68531 - Flags: needs-work+
Comment on attachment 68531 [details] [diff] [review]
incorporate bbaetz's comments

Wrong Patch - Sorry for the confusion.
Attachment #68531 - Attachment is obsolete: true
Whiteboard: [patch needs r/sr=]
Comment on attachment 68840 [details] [diff] [review]
really incorpoarting bbaets's comments

sr=darin

remember to submit "cvs diff -u" patches in the future.
Attachment #68840 - Flags: superreview+
Bbaetz, Gagan
Can I get a r on this one ?
Comment on attachment 68840 [details] [diff] [review]
really incorpoarting bbaets's comments

r=bbaetz
Attachment #68840 - Flags: review+
Fixed with checkin
Checking in nsHttpHandler.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v  <--  nsHttpHandl
er.cpp
new revision: 1.48; previous revision: 1.47
done
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I've been searching for this problem for awhile, vinay, darin thanks for fixing
it.. 


I notice this alot on dialup, when opening alot of tabs for webpages.  I had
assumed it was my ISP killing my connection or Moz just goes dead after awhile
(without a clue per say).  To workaround it, I have had to kill Moz, and the
dialup connection then connect again to get me to connect to websites again.
this may have caused a crash... see bug 125405.
backed out my fix for the moment.
Trying to figure out what is causing bug 125405
nsHttpHandler is back tosame state as version 1.47
C:\newTree\mozilla\netwerk\protocol\http\src>cvs diff -r 1.47 nsHttpHandler.cpp

C:\newTree\mozilla\netwerk\protocol\http\src>cvs commit nsHttpHandler.cpp
Checking in nsHttpHandler.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v  <--  nsHttpHandl
er.cpp
new revision: 1.49; previous revision: 1.48
done
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
updated patch.
uses RemoveElementAt instead of RemoveElement.
Added some logging and null checking/assertions.
*** Bug 125405 has been marked as a duplicate of this bug. ***
whoops!  vinay: can you figure out why we're reaching this code so easily?  how
can there be so many connections on just one page view?  is mMaxConnections
initialized correctly?
Attached file showing the state of connections (obsolete) — 
We seem to be popping whenver we exceed mMaxconnections=24 which is ok. 
Look for the word popping in the attached http log. 

However, it does look to me that we are exceeding mMaxConnectionsPerServer. 
For ex:
0[3c5128]: ActiveConnection[0]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[1]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[2]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[3]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[4]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[5]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[6]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[7]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[8]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[9]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[10]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[11]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[12]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[13]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[14]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[15]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[16]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[17]=[conn=38a8528 host=a4.g.akamai.net:80]
0[3c5128]: ActiveConnection[18]=[conn=38a8528 host=a4.g.akamai.net:80]
Comment on attachment 69815 [details]
showing the state of connections 

Please ignore this listing. The debug messages were wrong.
Attachment #69815 - Attachment is obsolete: true
Please ignore comment 88 and attachement 69815. My debug statements were wrong.
With correct debug statements I find that:
The reason we are creating so many connections on one page view is a result of
going to different akamai servers.
We pop a connection once active+idle > 24.
Max Connections per server is not exceeded either since each of the akamai
servers has a different hostname.
All is ok. Nothing to worry here.

Darin can u please sr this so that it can be checked in.
Since topcrash 125405 has been duped to this bug, I am transferring its keywords 
, severity and signature for Talkback tracking. It is still on the topcrash 
lists for the Trunk. Once Darin sr's and Vinay checks in we can verify the fix.
Severity: normal → critical
Keywords: crash, topcrash
Summary: Intermittent "connection refused" errors → Intermittent "connection refused" errors [@ @nsHttpHandler::GetConnection_Locked]
Comment on attachment 69628 [details] [diff] [review]
use RemoveElementAt instead of RemoveElement

sr=darin
Attachment #69628 - Flags: superreview+
It looks like we got the sr= last night...is this going to make it into M099? 
Just curious.
Summary: Intermittent "connection refused" errors [@ @nsHttpHandler::GetConnection_Locked] → Intermittent "connection refused" errors [@ nsHttpHandler::GetConnection_Locked]
Rick, Gagan, Bbaetz
Can one of u folks please r= this one again ?

Comment on attachment 69628 [details] [diff] [review]
use RemoveElementAt instead of RemoveElement

r=bbaetz
Attachment #69628 - Flags: review+
a=asa (on behalf of drivers) for checkin to 0.9.9
Keywords: mozilla1.0 → mozilla0.9.9+
Fixed with checkin
D:\mozilla\netwerk\protocol\http\src>cvs commit nsHttpHandler.cpp
Checking in nsHttpHandler.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v  <--  nsHttpHandler.
new revision: 1.50; previous revision: 1.49
done
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
verified fixed.  talkback data shows this last crashed with MozillaTrunk build 
2002021413...which seems weird since the original checkin was backed out on 2/14
and the new one checked in 2/22.  did another checkin maybe fix this crash on 2/14?
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsHttpHandler::GetConnection_Locked]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: