107776 - NNTP error (like "400 Too_Many_Connections") seems to cache selected article even though the article is not download

Status: RESOLVED FIXED

(MailNews Core :: Networking: NNTP, defect)

Description

[Henrik Gemal]

Sometimes when reading newsposting on news.mozilla.org I get:
400 Too_Many_Connections
the problem is not so much getting this error the problem is that the article
that I selected just before I try to get this article (the article is not
downloaded because of the error) seems to get into a state where mozilla think
it has downloaded the article. 

Meaning that if you go on and read another article and then go back to the
article where you got the error 400 the message pane is just blank. Mozilla
seems to say "hey I already downloaded this article so no need to get it again."
But since mozilla never downloaded the article in the first place the article
seems lost!

build 20011031

Comment 1

[Håkan Waara]

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

Comment 2

[Håkan Waara]

I've started seeing this all the time now. Upon almost every third article or 
so I read, I get this error.

As Henrik mentions, this is dataloss, and should probably be a 0.9.6 stopship 
for news.

Comment 3

[Håkan Waara]

My best reproducible step is to collapse the news account twisty. This does not 
seem to be related to the time you have kept Mozilla open; sometimes it happens 
on startup.

Comment 4

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

I occasionally see the "Too_many_connections" bug when trying to get the list of
newsgroups in the subscribe window

Comment 5

[Håkan Waara]

I'm having trouble reproducing this.

Gemal, Stephend, do you guys have a bullet-proof testcase for this?

Comment 6

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

No, I believe it occurs when the server is throttling connections left and 
right (like when news.mozilla.org and several network paths here @nscp were 
being upgraded).

Comment 7

[Håkan Waara]

I think stephend is right; I haven't seen this in months now.  Lowering severity
slightly due to this.

Comment 8

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 9

[zug_treno]

Related to bug 108203 ?

Comment 10

[Boris 'pi' Piwinger]

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

Comment 11

[Boris 'pi' Piwinger]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030331
still has this problem. Unrecoverable dataloss should really be fixed. Asking
for blocking 1.4b.

pi

Comment 12

[Pascal Byrne]

Still present in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4RC1)
Gecko/20030529. 

It is now more than a year and a half since this was reported. Why does it still
not have a target milestone?

Comment 13

[Christian Eyrich]

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

Comment 14

[Boris 'pi' Piwinger]

Since this is dataloss, I ask for blocking.

pi

Comment 15

[Asa Dotzler [:asa]]

Since we don't have any force reload mechanism, this would be nice to get fixed
but not going to hold the alpha release for this. Who can look into the problem?

Comment 16

[R.K.Aa.]

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

Comment 17

[Asa Dotzler [:asa]]

not going to block the release on this. is there someone on the cc: list who
could pick this up and help get a patch or line of investigation on a patch going?

Comment 18

[Boris 'pi' Piwinger]

Asking for blocking in 1.8a because of dataloss.

pi

Comment 19

[Joe Smith]

(In reply to comment #12)
> Still present in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4RC1)
> Gecko/20030529. 
> 
> It is now more than a year and a half since this was reported. Why does it still
> not have a target milestone?

This bug has been open for more than three years, and is still present in
Thunderbird version 0.9 (20041103).
The failed message is being cached as zero bytes long.

Comment 20

[Boris 'pi' Piwinger]

Since this is dataloss, I ask for blocking once more.

pi

Comment 21

[Serge Gautherie (:sgautherie)]

I read in one of the duplicates that scott wrote that the same kind of issue was
fixed for IMAP...

Now, where is the "cached" state of the message set ? Where is the download
happening ?

Comment 22

[David :Bienvenu]

taking. I'll look at this today.

Comment 23

[David :Bienvenu]

this is not dataloss - the message is still on the server, and the next time you
run the client, we'll fetch the message. What's happening is that there's an
empty message in the memory cache - this is not referrring to the offline store,
as I previously thought.

Comment 24

[Boris 'pi' Piwinger]

I don't use Mozilla for News anymore, but last time I checked it was absolutely 
impossible to get Mozilla to fetch the message. So the data was lost to the 
user. So this is in fact dataloss.

pi

Comment 25

[Anton Solovyev]

(In reply to comment #24)
> I don't use Mozilla for News anymore, but last time I checked it was absolutely 
> impossible to get Mozilla to fetch the message. So the data was lost to the 
> user. So this is in fact dataloss

It is true that if Mozilla is restarted the "lost" messages can be downloaded
fine. I see this error probably 3-5 times every day, since my news server starts
rejecting connections when they come at too high rate. I have to restart Mozilla
to get to see those messages.

Extremly annoying, BTW.

Comment 26

[David :Bienvenu]

Attachment: proposed fix

if we get an error, doom the cache entry. Also, don't disconnect if the error
is just article not found.

Comment 27

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

Comment on attachment 174381 [details] [diff] [review]
proposed fix

a=sspitzer for 1.8b

Comment 28

[David :Bienvenu]

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

Comment 29

[David :Bienvenu]

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