Closed Bug 65927 Opened 24 years ago Closed 24 years ago

News leaves connections to server open (too many connections)

Categories

(MailNews Core :: Networking: NNTP, defect, P1)

Product:
MailNews Core
Component:
Networking: NNTP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: mozilla, Assigned: naving)

References

Details

(Whiteboard: [nsbeta1+])

Attachments

(12 files)

News Log showing connections being left open.
45.09 KB, text/plain
Details
Another Log showing problem after check-in (Jan 25)
113.49 KB, text/plain
Details
proposed fix
957 bytes, patch
Details | Diff | Splinter Review
My latest log on Windows 2000, build 2001030920
22.95 KB, text/plain
Details
fix
2.45 KB, patch
Details | Diff | Splinter Review
Log file from build 2001032604 on Windows 2000.
9.56 KB, text/plain
Details
Same build, OS, but with patch applied. (Same 5 messages read, also)
10.79 KB, text/plain
Details
Build 2001042920 using @home network.
32.21 KB, image/jpeg
Details
Log file; I have 9 NNTP connections open right now.
13.99 KB, text/plain
Details
Same log file; # of connections reached 48 and stopped growing
53.32 KB, text/plain
Details
proposed fix
1.60 KB, patch
Details | Diff | Splinter Review
revised patch
1.15 KB, patch
Details | Diff | Splinter Review
My news server has a limit to the number of connections I can have at any one time. When I start reading through messages, Mozilla leaves a connection open untill (I believe) it times out. This causes a bit of a problem because I can't just flip through all of the messages in a newsgroup because eventually I get a message saying... "Too many connections from [username] at [IP Address]" I don't know how exactly to describe this bug other than that. I find that there is an error message every once and a while stating "Unknown Error" and that after I dismiss that dialog, I can make one more connection. (I assume this is the news server dropping me after inactivity.) These dialogs keep coming up and I get one more connection each time. This gets tedious as you can imagine. Is there a reason that mozilla keeps connections open? Is there a way to configure the number of connections... or should they all be closed after each message? I don't know much about the workings of news, but from my deductions, this is what appears to be the problem.
cc'ing bienvenu, he just logged a similar bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → stephend
I'm sure it's the same bug. Mike, can you attach an NNTP protocol log? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
I've attached a NNTP Log. Not sure what it means, but there are certainly alot of lines. Here's what I did... Loaded Newsgroup, Clicked on several messages right after the previous finished loading, Continued until I recieved the "Too Many Connections" error, tried another message to get the error again, waited until the server dropped me (and i got "Unknown Error") then read another message (actually 3 -- one for each "unknown Error") Hope This helps.
All of those greetings from the server do indeed show the multiple connections. David fixed this on the 22nd, and I just verified bug 65975 on Windows and Mac. It looks like this: (server string)+ NNRP ready (posting ok). Marking as FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
VERIFIED FIXED.
Status: RESOLVED → VERIFIED
as I've mentioned to david, I'm still seeing this (or something very related). I'll figure it out and reopen this bug, or open a new bug.
This bug has not been fixed. I am still recieving the same problem as before. I browse a few messages and eventually get a "too many connections from [username]" if I wait untill I recieve an "Unknown Error" message then I can read one more message. Each "Unknown Error" (which I assume is connection timeout) gives me one more connection (or frees up one). I have attached another news log of the problem. Tested Build 2001012504 -- Jan 25
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
My fix was for posting only - it seems there's another bug having to do with just reading messages. Do you ever notice that it takes a long time to load a particular message (like up to a minute?) - I think that's related to this problem, somehow.
it is definitely having to do with reading messages. I've never posted a news message in my life, and I have this problem right now. Only allowed 3 open connections per IP for @home's news server, which runs out quickly when browsing through messages... Running 2001012708 on Win2000.
in the back of mind, I'm worried it is news biff. accepting. marking p1, since it makes the news readers stop working.
Status: REOPENED → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.8
I'm thinking you might be right, since news biff seems enabled by default now.
I suspect this was causing my 100% cpu useage as well, since it's stopped happening since I turned news biff off.
well, here's part of the problem. If we ever get stuck with the first connection in the cache marked busy, then we will forever after that open a new connection for every news url. I'll attach a patch to fix that.
Attached patch proposed fix — — Splinter Review
patch looks good. it took me a while to understand the code. sr=sspitzer re-assign to bienvenu.
Assignee: sspitzer → bienvenu
Status: ASSIGNED → NEW
sr=mscott
Please let me know if anyone sees this again. Thee is obviously a situation where connections get stuck in the busy state - previously, that would immediately cause this bug. Now, there will be one extra open connection for each falsely busy connection, but those should be rare.
bienvenu, should this be marked fixed?
No, I believe there's still a bug where connections get falsely stuck in the busy state. I think that accessing messages from the disk or memory cache can cause this.
Ok, This is still happening for me. Also, it has happened for a while now, so if biff was just turned on then that shouldn't matter since it happened for at least a few weeks. I can use 4.x to use my newsserver, so I am adding 4xp. I don't know whether you guys may be thinking about a different problem, or maybe they're related. The problem I have is that I get a "Too many connections" error, then a few minutes later I get an "unknown error" window and then I can make one more request to the newsserver. I don't know how else I can describe it, but if you have any questions just ask. I checked this with build 2001 01 30 10, and it still occurrs. I can get it to appear much quicker by viewing messages with attachments (Do messages have a seperate connection?)
Keywords: 4xp
attachments, especially inline attachments, could definitely cause a problem - we should be getting inline attachments from the memory cache, but mime will ask for each attachment as we're downloading the message, and if things don't work right, that will cause a separate connection to get made for each attachment.
moving the rest of the bug to future milestone.
Target Milestone: mozilla0.8 → Future
*** Bug 66890 has been marked as a duplicate of this bug. ***
Adding Mozilla0.9 keyword. This bug is really a problem, in that I can no longer use newsgroups in Mozilla. This essentially leaves the News Portion of the program useless to me. This and bug 67213 appear to have the same culprit. Somehow connections get left open in the "busy" state. (This is if I am interpreting the bug right.) I'm not sure exactly what part of the bug was futured since I am still getting the exact same problem, but hopefully this can get fixed before rtm. You said that if I turn off biff, I might be able to get around this problem. How exactly does one go about doing that? If I can try a build without biff, I can tell you whether biff is the culprit.
Keywords: mozilla0.9
I agree, this bug has a P1, and David might be overburdened with Offline functionality. Adding Scott and Seth to the list (since it deals with attachments also and news.)
*** Bug 68458 has been marked as a duplicate of this bug. ***
The NTTP logfile I attached show me just reading messages, which is the precise problem the reporter had in this bug. Nothing looks out of the ordinary to me.
This bug is really only visible on servers which have a low limit on the number of connections. (Like my ISP) I should be able to get you a log on tuesday of my machine with the latest build. Unless something has happened with the connection cache however, I don't think it has changed since the last build I had. Also, this is much more apparent with groups with attachemnts because a seperate connection is formed for each attachement (or at least thats what it seems like.)
I am using build 2001031604. I am allowed 3 connections when I read news (Prodigy Internet remote news). After reading any 3 messages in rapid succession, whether or not they have attachments, the fourth message pops up with an error saying "Too many connections open. Connections allowed == 3." It seems to me that attachments don't matter, but maybe they do in some cases.
james, based on your comments, and the code in nsNntpIncomingServer::GetNntpConnection(), I could see how this could happen. it looks like if all the current connections are busy, we spin up a new one. line 553, nsNntpIncomingServer.cpp // have no queueing mechanism - just create the protocol instance.
I noticed this bug is marked as windows, but I have the exact same problem on Linux (Build 2001032405). Should the OS be changed to All?
sure, all.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
*** Bug 73455 has been marked as a duplicate of this bug. ***
I'm seeing this on recent builds. posting messages seems to leave the connection open. I've got 12 connections open to news.mozilla.org
fix in hand for the problem I am seeing. which is posting opens continually spins up new connections. nsNntpServer::PostMessage() was creating calling GetProtocolForUri() twice! once on it's own, and once when it called RunNewsUrl().
OK, well that solves a part of the problem. The main problem on this bug is that connections that are opened aren't reused. Instead, new ones are opened and we (on limited connection servers) get stuck with "too many connections from: " errors. then we have to wait until the connections time out before we can connect again. I was snooping around the code with my puny excuse for coding talent and found some interesting things. 1. What does line 490 in nsNntpIncomingServer.cpp do? it says /* By default, allow the user to open at most this many connections to one news host */ 490 #define kMaxConnectionsPerHost 2 is this suppossed to be some sort of hard coded limit? (because if it is its not being enforced) 2. The GetNNTPConnection function (493-557) is a little confusing (besides the indenting) how does a connection get set as busy? This looks like one of the main things that could be causing new connections to be made every time. I will attach a News Log from my machine again since some stuff has gone in to clean up NNTP since I last put one up.
no, the hard limit is not enforced. If it was, with the way we're leaking connections, you couldn't use news. A connection is busy if it's running a url - put another way, running a url with a connection marks it busy. If connections are invalidly left in the busy state, that would cause us to leak connections. Yes, this is the most likely cause of the problem, but, ironically, we have not found this to be the case, yet.
yes, the limit is not respected. we'll create more connections if cache is full of what we think are busy and non-timed out connections. on a related note, I've got another change in my tree for when a connection does time out (170 seconds of idle) my patch makes it so we close the once we think it has timed out. I think that without this patch, we'd might take the connection out of the connection cache, but leave it open to the server. I'll attach my patch to the news code tommorow for review.
sr=bienvenu
Here's a log file of current *unpatched* behavior. I subscribed to the newsgroup netscape.test on news.mozilla.org and read the 1st 5 messages. Then I did a File | Quit.
mike young, the current code will re-use the nntp connections. stephend, thanks for the nntp logs. to see how many connections we are opening, look for "creating a new nsNNTPProtocol" in the first log, we are creating one connection to the server. in the second log, we are creating two. I'll land this patch today.
my fix has landed. posting is much more connection friendly, as are timed out connections. I'm tempted to mark this fixed, and spin off the other issues (example, not respecting the limit) into other bugs.
I believe you are right. I just tried to browse the newsgroups and couldn't reproduce this. I tried and tried and tried untill my log file was enormous and didn't get the error. BUT.... I cant test attachemnts because inline attachments with the new imglib seem to crash mozilla. (going to download new build tonight) I DID recieve the error (too many connections) if I pressed N (for next) to fast so that it requested a new article before finishing the one before. -- I think this is because we dont close (or clear-out) the connections for articles we are not reading. (Although it would be nice to just download it in the backround like outlook does. :-) Now this would be fixed i guess by enforcing the max-connection limit (id like this to be a pref defaulting at 3 but i guess its just a dream.) On the note of opening a new bug for enforcing the max-connections, that one already exists. its bug 66150 Otherwise, I think that this bug may be fixed. Id wait to confirm it though untill the inline attachments start working again. (which i think was one of those 24hr bugs.) Thanks alot, I can start using news again.
Seth, I think you should mark this fixed. We've got plenty of other bugs on not respecting the limit, and opening too many connections (due to the subscribing to images, etc.)
fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Well, I am going to mark this verified. I can no longer get this error unless i really try and download multiple news messages with attachments at the same time. I believe these will be fixed when: News uses the cache when someone chooses to save an attachment News has a max-connection pref that will prevent the error all-together. bug 66150 Meanwhile, I have now started to prominently see the "Unknown Error 80004005" alert that i reported in my first post. (I guess now that I can use news, errors are easier to spot :-) I opened a new bug for that one in bug 74081 Thanks for all your help! i now have one less reason to continue using NS4.x
Status: RESOLVED → VERIFIED
Ah yes, this is enormously better now (on Telocity's NNTP server, which allows 2 connections at a time). Thank you!
*** Bug 72341 has been marked as a duplicate of this bug. ***
I still see this behavior as of build 2001040912, which is after the fix date, if I understand the build naming correctly. I see it when viewing more than 5 images in a.b.p.anime. The 6th returns an error from the news server saying, only 5 auth-connections allowed.
Is it possible/probably that we've regressed since the mail/news cache changes have landed?
I thought the same thing and am going to try to recreate the problem on my machines. I'll update with whether I see it soon. I thought that not all of news was switched over to the new cache though. Especially attachments, bug 74518 dealt with opening a new connection when saving attachments. If someone tries to save the attachments then moves on to the next message without letting it finish, they will definately get this error since the connections are busy. Can someone enlighten us on which parts of the news networking are now using the new cache?
Im not able to reproduce this on my windows machine running 2001422. The only way I can get the message is if i click a whole bunch of messages in a row really fast so there are busy connections in the queue. The throbber/progressbar seems to have been broken recently in news however, so I have no idea when something is done loading. This doesn't help testing... Hal, If you could download a recent build and try to see whether you still get the message it would help alot.
Okay, I downloaded a more recent build than the 2001.04.09 one" today's "latest" snapshot from mozilla, and I was able to read quite a few more than my connection limit of 5 articles with no problems! Of course it is build 000000000 because I built it myself, so I assume the official build will work if mine did. So, no reason to be alarmed. Good job on the fix, all!
I'm still seeing this problem on 2001-04-26-08 Linux. The @Home news server only allows 5 connections, so it seems... Even after closing the mail/news window, the connections don't seem to go away until the news server kills them (I am guessing it is some kind of timeout since it takes a good 5 minutes.) I haven't tried posting anything -- this problem just crops up after reading a few messages at a fairly normal reading speed.
Okay, I saw this today (attaching screenshot), but I had to click in rapid succession and on the sixth message load this is what I got.
This is odd, because I was seeing this behavior before with the Linux Mandrake 8.0 RPM version (4/9/01) but when I compiled it myself on 4/24, I didn't see this problem. After seeing your message, I compiled it again myself on 4/29 and still didn't see the problem. I also use @home with a 5 message limit. I see you two used precompiled versions, maybe this makes a difference? I use no options to configure, and my build ID comes out as 0000000000. The security stuff seems not to be included when I build it myself. Maybe the build has something to do with it? I tried downloading the nightly binary .tar.gz for 4/29 and tried to use it, but I couldn't get it to do anything at all. (but I am probably doing something wrong)
From what I can tell the messages you see are from your news server and Mozilla just passes them along. I use a supernews server which allows (from what I can tell) 3 connections. The way mozilla works is by keeping a list of open connections and reusing them as long as they are not in a busy state. What I have found is that if you click to download messages rapidly, or click to download another message before the previous one has finished, you will leave that connection in a busy state, and force the computer to open a new one. I believe this will be more noticable for people on a dialup connection, because they will have a lot more time to wait until the message is loaded. Since I am on a T3 here at school, I can't really reproduce it. This is where this bug stops and several others come into play. bug 66150 deals with institutinig limit to the number of connections mozilla will try to make. It would be ideal for that bug to be fixed by a pref which sets the number to 3 so that if connections are busy, mozilla will either kill them (Like 4.x did) or will wait until they are done. Vote for that bug!!! For all intents and purposes this bug has been fixed. If you guys could try downloading a message, letting it complete (watch the progress bar), then doing it again, and again, you should not be able to reproduce this bug. But if you can reproduce it by downloading messages before the previous one finished, then that is bug 66150. Another thing to note... Messages with attachments really aggravate this problem because the attachment is downloaded as well... so if someone doesn't want to sit through the download, they just leave the connection busy. I don't know whether the stop button moves the connection out of busy either. Hope this helps.. If you guys still see the problem please post a message and perhaps a log file is you can. how to do so is at ... http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html
*** Bug 76138 has been marked as a duplicate of this bug. ***
Blocks: 76449
I am afraid I am still seing this problem. I am using the RPMs from nightly/2001-05-04-11-0.9 recompiled on RedHat Linux 6.2 I have Mozilla set to check for new messages on this NNTP server every 10 minutes. If I leave Mozilla alone, and come back in a few hours, it turns out it has a lot of NNTP connections open to that server (last time I checked, it opened 47). The other nastly thing about this behaviour, is that Mozilla runs out of some resource when it does this and after it opens all these connections, it is uncapable of opening new ones (even HTTP ones) until I restart it.
I still have this problem with Mozilla 0.9 on RedHat Linux 6.2 I have it set to check for new messages every 10 minutes. The server requires authentication and it seems that all these hanging connections hang at authentication stage (even though PSM has login&password and it is unlocked). I'll try to generate a log later today.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'll set up biff and see if I can reproduce. thanks for all the info.
Assignee: bienvenu → sspitzer
Status: REOPENED → NEW
Target Milestone: Future → mozilla0.9.1
reassigning to self.
Assignee: sspitzer → naving
I set up the biff interval to 1 min and left mozilla running for an hour or so, There is just one open connection to news.mozilla.org. May be when we fail on authentication we are not closing the connection.
Navin, can you try a server that requires authentication? Also, a lot of the comments sound like clicking on messages before others have had a chance to finish loading is required.
Yes, this definitely seems related to the fact that the server requires authernication. It's not clear: - Why Mozilla has trouble authenticating after I gave it auth info? Works fine for POP-3, why problems with NNTP? - Why Mozilla fails to close the connection when it decides it does not have a chance to authenticate?
> Also, a lot of the comments sound like clicking on messages before others have had a > chance to finish loading is required. > The problem I am seing happens even with no clicking at all.
I've seen this on my system where the NNTP doesn't require authentication. But I do believe I may have clicked on more than one message before the first has completed loading. But even after waiting for a bit, I get a message that there are too many NNTP connections open.
Attached patch proposed fix — — Splinter Review
We were not closing the connection when there is an NNTP_ERROR (like authentications fails). Also when we type wrong user/pass the throbber was still going. I made it so that it stops now. Need review.
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Another problem here is that it is not really "authentication fails", it's Mozilla deciding not to authenticate even when it has no reason not to. I filed bug #81580 about this problem.
From the NNTP log we can see that the authentication process begins and it ask for the username and then it fails for some reason. From the code it looks like username/cachedUserName is null which causes the next state to be NNTP_ERROR. The next time you hit GetMsg() the same thing gets repeated and we have as many open connections as the number of time you hit GetMsg(). The fix attached will close such connections. Try not using the password manager for user/pass, type them when prompted. if user/pass is wrong you should get an error "542 Authentication failed .." from the server If the server says "authentication failed" then it will close the connection on mozilla and there should be no open connections.
That's the funnty thing - if I press GetMsg, I do get the dialog asking me for user/pass and everything works. However, if I just set Mozilla to check for new messages every xxx minutes, then I never get asked for the auth info and Mozilla just keeps creating connections that never go away...
reviewing and testing this patch now.
comments - if(pauseForMoreData) + if(pauseForMoreData && line) why was that change needed? + return CloseConnection(); I'll need to test and see if that is safe. - if (mailnewsurl) + if (mailnewsurl){ + mailnewsurl->SetUrlState(PR_FALSE, NS_OK); what affect will that have on the other times we call SetUrlState()? by moving it there, we'll be calling SetUrlState() twice in certain cases. it sounds like naving has found the root of the problem: we don't close the connection on error. from other comments, it sounds like auth and biff aren't playing nice either. I'll start with naving's patch and his findings. we've got to be careful with the protocol code. it's easy to accidentally break.
naving has explained his fix to me, and it makes sense now. r=sspitzer naving's fix will prevent us from opening up too many connections. after this lands, there will be a case (from the comments above) where we'll biff, fail to authenticate, close the connection, biff, fail to authenticate, close the connection. that will put stress on the server. I'll check what we do in the mail case. we might not biff if we aren't properly authenticated. I'll start a new bug on that.
Attached patch revised patch — — Splinter Review
closeConnection() removes the connection from cache and also does cleanupRunningAfterUrl() so need to set the next state to NEWS_FREE; Also moved the mailnewsurl-SetState(PR_FALSE, NS_OK) from NEWS_FREE to cleanupAfterRunningUrl() because this should also get executed when the server closes the connection on mozilla.
sr=bienvenu
r=sspitzer make sure to give good a good testing before checking in. see http://www.mozilla.org/quality/mailnews/tests/sea-mn-newsgroup-function.html for all the tests. (no need to run them all, but give it a good testing.) specifically, test viewing a cancelled article. there's an existing bug about how viewing a cancelled article will (incorrectly) cause us to close the connection. that bug isn't fixed, but you should test it out. also test the case where drop the connection because it timed out.
fix checked in. Aleksey, can you verify this bug ?
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I can try, but after the bug #75007 was fixed, biff started (finally!) asking for auth info instead of going to NNTP_ERROR, so I am not sure I'll be able to reproduce the old behaviour accurately.
Build id 2001052210 on RedHat Linux - Mozilla does close the connection, although the logged messages look weird and in particular, it tries to send "QUIT" twice intead of once: 1024[8054498]: Receiving: 480 Authentication required - login: 1024[8054498]: Next state: NNTP_BEGIN_AUTHORIZE 1024[8054498]: ask for the news username 1024[8054498]: Next state: NNTP_ERROR 1024[8054498]: ClosingConnection on nsNNTPProtocol(4155e6a8) 1024[8054498]: Sending: QUIT 1024[8054498]: Next state: NNTP_ERROR 1024[8054498]: ClosingConnection on nsNNTPProtocol(4155e6a8) 1024[8054498]: Sending: QUIT 1024[8054498]: ClosingSocket() on nsNNTPProtocol(4155e6a8) 1024[8054498]: CleanupAfterRunningUrl() 1024[8054498]: destroying nsNNTPProtocol(4155e6a8)
Status: RESOLVED → VERIFIED
I'm seeing this behavior on Build ID: 2001052420, Windows 2000. I can read articles no problem, but if I save an attachment, bam! After that, I get the "too many open connections" error dialog when attempting to read another article. - Kyle
The problem with attachments is bug 74518. It deals with the fact that we aren't saving attachments from the cache, but instead redownloading them. This will cause you to use up another connection. If you are seeing this, please comment in that bug, because it needs some attention. :-)
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: