70605 - tcp connections never closed when checking for messages on pop server

Status: VERIFIED WORKSFORME

(MailNews Core :: Networking: POP, defect, P2)

Description

[Dave]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.9) Gecko/20010228
BuildID:    2001022809

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 (it was later up to 409 when I forgot to shut down mail/news over the
weekend)... 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 that the "CLOSE_WAIT" status may indicate that the server
it's connecting too isn't reponding to the close request, in which case it may
not be Mozilla's problem.

I'm behind a "transparent firewall".


Reproducible: Always
Steps to Reproduce:
1.) Configure pop3 account
2.) Set it to automatically check for new messages at intervals (I have it set
not to download automatically).
3.) Leave mail/news running for some time (I run it in a separate terminal from
the browser with mozilla -mail).
4.) After it has checked for new messages on the sever several times, run
netstat and check for entries like I described above.

Actual Results:  Connections stay in CLOSE_WAIT state indefinitely

Expected Results:  Connections should be closed after checking for new mail.

The only other bug I found that might be related is bug 67957 (Too many sockets
open).

Comment 1

[Dave]

Just talked to a co-worker who wasn't seeing this problem on 20010118 but, upon
upgrading to 2001030609, started seeing it also.
We also figured out that the mail server isn't outside the firewall so that
(along with the fact that the firewall is transparent) would seem to suggest
that the firewall isn't an issue.

Changing summary.

Comment 2

[Navin Gupta]

May be it is related to nsMsgProtocol::CloseSocket() where we just delete the
stream and not close it. I 'll investigate

Comment 3

[Navin Gupta]

accepting. I am also seeing this.

Comment 4

[Navin Gupta]

nominating

Comment 5

[Navin Gupta]

cc bienvenu 

Comment 6

[David :Bienvenu]

I think Scott knows a lot more about this stuff than I do.

Comment 7

[scottputterman]

marking nsbeta1-

Comment 8

[scottputterman]

I marked the wrong bug. This one hasn't been evaluated yet. removing nsbeta1-
for the moment.

Comment 9

[Dave]

For what it's worth when this is evaluated, I find it pretty annoying...

Comment 10

[Navin Gupta]

This problem is a regression between 2/20 (not reproducible) and 
2/22(reproducible) . I see most of the changes being related to necko carpool. 
cc dougt for his comments

Comment 11

[scottputterman]

marking nsbeta1+

Comment 12

[R.K.Aa.]

Just built a cvs build applying the patch from bug 71391, and this now WFM.
(I think it's a dup of bug 67957 btw)

Comment 13

[Navin Gupta]

marking worksforme now, based on the previous comments.

Comment 14

[Dave]

vrfy