Dump of Windows' netstat -n. All of these sockets were opened by Mozilla. Note: 192.170.10.30 is an internal server, on which I hadn't read news yet... Active Connections Proto Local Address Foreign Address State TCP 127.0.0.1:1076 127.0.0.1:1077 ESTABLISHED TCP 127.0.0.1:1077 127.0.0.1:1076 ESTABLISHED TCP 192.170.10.111:1287 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1288 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1289 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1300 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1301 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1302 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1315 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1316 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1317 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1343 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1344 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1089 194.205.129.7:143 ESTABLISHED TCP 192.170.10.111:1345 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1359 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1360 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1361 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1368 194.205.129.7:143 ESTABLISHED TCP 192.170.10.111:1113 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1114 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1115 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1378 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1379 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1380 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1401 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1402 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1403 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1150 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1151 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1152 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1417 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1418 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1419 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1431 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1432 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1433 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1452 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1453 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1454 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1476 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1478 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1483 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1484 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1252 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1253 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1254 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1270 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1271 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1272 192.233.80.227:119 ESTABLISHED

I'm thinking that it's biff. Biff was turned on for news by default.

what build were you using? this may have been fixed by the news connection cache that was added within the last month.

I noticed this a few weeks ago, when comparing netstat output between IE and Mozilla.Mozilla always seems to open far too many sockets and doesn't close them when it should.Working through college proxy now, so I can't check this out, but perhaps someone else should.Would this impact upon download times in any way? FTP downloads,for instance, always appear significantly slower with mozilla than with IE.

try a more recent build. this has been fixed.

Agreed, I just checked on build 2001020904, I had only two port 119 connections. VERIFIED.

Sorry, but I got this with build 2001020904 as suggested: Active Connections Proto Local Address Foreign Address State TCP 127.0.0.1:1594 127.0.0.1:1595 ESTABLISHED TCP 127.0.0.1:1595 127.0.0.1:1594 ESTABLISHED TCP 127.0.0.1:1597 127.0.0.1:11111 ESTABLISHED TCP 127.0.0.1:1599 127.0.0.1:1600 ESTABLISHED TCP 127.0.0.1:1600 127.0.0.1:1599 ESTABLISHED TCP 127.0.0.1:11111 127.0.0.1:1597 ESTABLISHED TCP 127.0.0.1:1467 127.0.0.1:1468 ESTABLISHED TCP 127.0.0.1:1468 127.0.0.1:1467 ESTABLISHED TCP 192.170.10.111:1540 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1541 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1542 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1556 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1557 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1558 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1605 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1606 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1607 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1612 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1613 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1616 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1617 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1619 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1624 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1625 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1636 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1637 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1638 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1643 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1644 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1660 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1661 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1662 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1685 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1686 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1687 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1701 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1702 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1703 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1715 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1472 194.205.129.7:143 ESTABLISHED TCP 192.170.10.111:1475 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1476 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1734 194.205.129.7:143 ESTABLISHED TCP 192.170.10.111:1479 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1480 194.205.129.7:143 ESTABLISHED TCP 192.170.10.111:1506 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1507 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1508 192.233.80.227:119 ESTABLISHED TCP 192.170.10.111:1525 198.95.249.40:119 ESTABLISHED TCP 192.170.10.111:1526 192.170.10.30:119 ESTABLISHED TCP 192.170.10.111:1527 192.233.80.227:119 ESTABLISHED

Okay, how many news *servers* do you have open in the folder/server pane? (I mean with the twisties expanded.)

Just the three, all expanded, all set to check for new messages: 198.95.249.40 secnews.netscape.com 192.170.10.30 (private news server) 192.233.80.227 support-forums.novell.com

what's the interval of the check for new messages? i.e., how many minutes?

All are set to 10 minutes. I have just opened Mail & News and see only three :119 connections. I then advanced to n.p.m.ui and I now have six. Also I saw status messages that Mozilla was checking for new messages. Should I try downloading a newer nightly? I'm still on 2001020904.

It seems Mozilla is checking all servers for new news when I change folders :-(

when you say folders, do you mean newsgroups, or mail folders?

Slight correction. While mozilla appears to recheck all groups on the same server when selecting a news folder, this does not per se appear to use up sockets. Adding hang keyword because running out of sockets can cause Mozilla to hang.

Does it hang for you?

neil, before you select the newsgroup, are you expanding the news server? if upon expanding a news server (clicking on the twisty to left of the news server in the folder pane) will cause us to go do a "GROUP" on all newsgroups in the server. expanding a news server will cause us to one a single url (news://newshost), so at most that would be using one connection. can you get a NNTP log for us to look at? see http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap for how to do that. thanks for your help

Eventually I stop being able to browse or read mail or news or use other TCP/IP applications although Mozilla appears to keep responding until I try to close Messenger at which point it hangs and I have to zap it. I don't manually open news servers because they persist. I'll try to get a log.

starting up with a news server expanded will also automatically get the counts for the groups.

if you launch mailnews, and the news servers are open, we have JS that acts like you started up with them closed, and then manually opened them. the reason for this trickery, is so that we'll update the unread counts on start up. (there is a bug on me, to delay this, because it slows down startup time)

ah, this looks like the bug where images in news messages cause us to subscribe to news folders (and probably make connections for them). I believe this is caused by imagelib not correctly basing urls - we have a similar problem in imap. I'm not sure if there's a bug for it.

I think it was just bad luck that I happened to be log that rogue message...

Other people have reported that the problem happens after viewing news messages with images so I believe it is a common cause of this bug - see bug 65261 for a related imap issue.

I've turned Biff off for all my news servers, but I'm still getting a number of open sockets; it seems to grow by one every time that I read a group and an extra one if this involves a different server.

2001022209/Linux. Possible occurance of this bug: I believe I'm seeing this problem with mail/news. After a time, browsing gets really slow (network connections in general get really slow). I first noticed it when connecting to yahoo's mail server got _really_ slow. I ran netstat and observed a whole buttload of entries like the following: tcp 1 0 sesquipedalian.wco:2440 dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2439 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2437 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2436 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2435 dgproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedali:codasrv-se pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wc:venus dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2429 pmproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2426 pmproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2425 dgproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2423 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2422 dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2421 pmproxy00.wco:pop3 CLOSE_WAIT I then decided to run 'netstat | grep pop3 | wc -l', which returned a staggering 55 entries... one for each time Mozilla had connected to the pop server to check for new mail (I ascertained this by counting the times it said "You have no mail" or "Y'all got mail!" in the terminal I ran mail/news from). Upon shutting down Mail/News, the count immediately drops to zero. I suppose it's possible that the "CLOSE_WAIT" status indicates that the server it's connecting too isn't reponding to the close request so this may be a problem with checking mail through a proxy server (I'm behind a "transparent firewall").

Seems this bug now got fixed with the patch attached in bug 71391

I had news.mozilla.org and news.mcom.com open, each with a single newsgroup (netscape.public.mozilla.mail-news for news.mozilla.org) and (comp.lang.javascript for news.mcom.com) and I clicked on about 30 messages in each group.

I really don't see this bug anymore. Stephend: Are you saying you still see it?

No, my netstat log of output that shows the network activity of two news servers shows only two NNTP connections, as it should. If there is additional network activity, that seems it would be caused by bug 66673. Darin Fisher checked in some Necko code that closed unnecessary connections and that probably helped us here. Marking worksforme.

I'm not quite convinced although I'll have to make another log file to be sure.

Bad news for build 2001031008 - the bug is still there. I have an NNTP log and netstat output of you want it.

Yes, please do.

I did a bunch of work on mozilla/mailnews/news on the mailnews performance branch, which mscott is going to land very soon. but I still believe there are ways to make us open too many connections. let's wait until after mscott lands to attack this bug. after mscott lands, the news code will be logging a lot more connection info to NNTP log, and should help us track this down.

I don't know if this is relevant in the light of Seth's comment, but a news biff occured while I was partway though reading a newsgroup (I was doing work at the time :-) When I returned to Messenger to read the next message, I got this error: Error! newsgroup server responded:no Newsgroup has been selected Perhaps the article has expired <U3dJnUGsAHA.348@talkto.centurasoft.com> (2135) Click here to remove all expired articles Reloading the message fixed the problem.

Just got and built a CVS tree (3/24/01) on Linux (Mandrake 7.2) and although the news reader is muchas rapido (great work!) and now quite usable, the too many connections bug is still here. It does appear to be image based, and I get a new connection each time I click "NEXT" to get the next article. (I'm using a single server and I'm not switching newsgroups, I'm simply reading the next article.) Consequtive netstat results are: (after letting previous connections time out) [root]# netstat -ap -n Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 100 0 192.168.0.100:1495 24.28.95.186:119 CLOSE_WAIT 6499/mozilla-bin ... (read one article) [root]# netstat -ap -n Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 68 0 192.168.0.100:1502 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 68 0 192.168.0.100:1501 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 100 0 192.168.0.100:1495 24.28.95.186:119 CLOSE_WAIT 6499/mozilla-bin ... (read a 2nd article) [root]# netstat -ap -n Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.0.100:1503 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 68 0 192.168.0.100:1502 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 68 0 192.168.0.100:1501 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 100 0 192.168.0.100:1495 24.28.95.186:119 CLOSE_WAIT 6499/mozilla-bin ... (read a third article) [root]# netstat -ap -n Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.0.100:1504 24.28.95.186:119 ESTABLISHED 6499/mozilla-bin tcp 0 0 192.168.0.100:1503 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 68 0 192.168.0.100:1502 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 68 0 192.168.0.100:1501 24.28.95.158:119 ESTABLISHED 6499/mozilla-bin tcp 100 0 192.168.0.100:1495 24.28.95.186:119 CLOSE_WAIT 6499/mozilla-bin ... After waiting a few minutes these all go away and I can view a few more articles with images. (my server says it only allows three active connections at once) duanev@io.com

Duane, have you tried this lately? We recycle open connections...

BTW I'm down to ~3 connections per NNTP server. Sorry for the SPAM.

*** Bug 96811 has been marked as a duplicate of this bug. ***

*** Bug 96411 has been marked as a duplicate of this bug. ***

Are anyone still seeing this bug on Windows? I used to see lots of open sockets on Linux, but nowadays only one per server.

Haven't checked for sockets or anything, but I have not gotten any errors to the effect of "too many connections" from any of my NNTP servers in a long time. (I used to get them a lot after using MailNews for a while) Win98, Win2k

I have 2 NNTP servers set up: news.mozilla.org * 5 newsgroups news.mcom.com * 1 newsgroup I had each of these newsgroups open in another separate 3 pane mail window, and each has a message selected. Here is the netstat output on my Windows 2000 machine, from build 2002-01-13-08: TCP netscape-yqa044:4671 continuity.mcom.com:nntp ESTABLISHED TCP netscape-yqa044:4674 ripley.aoltw.net:nntp ESTABLISHED TCP netscape-yqa044:4675 ripley.aoltw.net:nntp ESTABLISHED TCP netscape-yqa044:4676 ripley.aoltw.net:nntp ESTABLISHED This seems *much* better than it used to be. Neil, can you comment? Thanks.

C:\>tracert news.mozilla.org Tracing route to ripley.aoltw.net [204.29.187.156] C:\>tracert news.mcom.com Tracing route to continuity.mcom.com [205.217.237.112] So, for 5 newsgroups selected on news.mozilla.org, we open 3 connections on different ports. For the single news.mcom.com server, we of course only open 1.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

Looks like a dupe of 66150 to me.