67213 - message lost sending to newsgroup failed too many connections error

Status: VERIFIED WORKSFORME

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

Description

[Asa Dotzler [:asa]]

01013104 mozilla zip build on NT4

Summary:  Sending to a newsgroup (npm.mail-news) failed with a "too many
connections" error.  The message was copied to the sent folder on local but
never arrived at the newsgroup. 
I have tried sending a few more posts to netscape.test but did not receive the
error so I could not repeat the problem.
I was able to retrieve the content of my message from the sent folder so it
wasn't a complete dataloss but I think that this bug qualifies as some king of
dataloss since it appears to have sent (didn't return me to the compose dialog)
the message.

Expected result would be that the user is given a 'too many connections' error,
followed by a 'message failed to sed' error and is returned to the compose window.

Comment 1

[Asa Dotzler [:asa]]

adding dataloss keyword and setting the severity to critical. 

Comment 2

[Asa Dotzler [:asa]]

hmm, I should fix the summary to distinguish it from the other too many
connections bugs. maybe this is better.

Comment 3

[(not reading, please use [e-mail] instead)]

thanks for logging this asa.  due to other bugs (news biff and a connection
cache bug) this is happening to me all the time.

big time data loss.

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

If I'm not mistaken, first the news.mozilla.org server ran out of disk space, so
they swapped hardware.  I think when they reconfigured the server, they missed a
max TCP/IP inbound setting.  I know the server itself had problems.  Posting
today on netscape.test (with build 2001020308, Windows 2000 from news.mcom.com)
has no problem.  And I don't want to send test message to mail-news.  Perhaps
this specific case is a server issue (otherwise it should affect netscape.test,
too.  

Comment 5

[Asa Dotzler [:asa]]

I don't think that it's a server issue.  The failure to connect may have been a
server problem but the message should not be lost because of a failure to
connect.  If we fail then we must retrurn the user to his message compose window
with his message content intact.  We currently do not do this.  We drop the
message on the floor and the user thinks that it was sent. 

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Agreed, but why then don't I see this on netscape.test, if not a server issue?

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

Don't take that comment the wrong way, I agree something is awry here, I just
haven't been able to pin it down, either.

Comment 8

[Asa Dotzler [:asa]]

you have to reproduce the too many connections (or possibly other failures) for
this dataloss to happen.  

Comment 9

[scottputterman]

moving to mozilla0.9

Comment 10

[scottputterman]

removing mozilla0.9.  Now that the too many connections bugs seemed to have gone
away, is this still a high priority?

Comment 11

[Asa Dotzler [:asa]]

I'm not convinced that this was a result of the specific "too many connections"
problem. It could be the more general (and scary) problem that if we fail to
make a connection to the server that we've already destroyed the compose window
losing its data.  Let me repeat, the bug reported here is not the failure to
connect. The bug reported here is that we lose the message if we fail to
connect.  I think that severity critical is appropriate for dataloss bugs.  

Comment 12

[scottputterman]

ok, so if we fix 52329 as part of adding progress to the compose window then it
sounds like the dataloss portion of this bug will go away. 52329 makes it so
that the compose window doesn't go away until the message is sent.

Comment 13

[scottputterman]

adding nsenterprise+

Comment 14

[(not reading, please use [e-mail] instead)]

slide to 0.9.5

Comment 15

[grega]

marking nsenterprise-.

Comment 16

[(not reading, please use [e-mail] instead)]

moving out.

Comment 17

[Håkan Waara]

I don't think this is valid any longer, since we now wait for the msg to be sent
before we close the compose window (i.e., we have a progress window for this
very reason).  INVALID?

Comment 18

[Asa Dotzler [:asa]]

I saw a failure on the trunk a week ago and lost a message. It's not the norm,
the compose window seems to behave as expect the overwhelming majority of the
time. We can close this out I suppose and I'll file a new bug the next time my
unsent message is lost.

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

marking worksforme.  will keep an eye out for this in the future.

Comment 20

[[e-mail] (gone - use [e-mail] instead)]

Getting off my resolved list by verifying.  Asa/I/other will re-open or re-file
this bug when we see it again.