David A. Cobb Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007100620 GranParadiso/3.0a8
Build Identifier: nightly/2007-12-10-03-trunk

I am encountering very frequent network timeouts, possibly capacity problems for my ISP.

When the connection times out, the program displays a modal error box and nothing else gets done.
The box absolutely should not be modal.
The program should wait a few minutes and attempt to re-establish the connection.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

	David A. Cobb Reporter
	Comment 2 • 17 years ago

I respectfully disagree with Magnus.  Reading Bug#123440, it appears that is a failure to initially establish a connection.  This bug-report concerns a "network timeout" that occurs well into the download process.  Also, this is definitely happening in TRUNK -- not four years ago!

Furthermore, this bug requests a specific solution.  Simply "getting rid of the modal dialog" is not enough -- the program should attempt to restart the download process.

Watching the NSPR_LOG_FILE, it appears the time-out always occurs after the "." end-of-message line is received, but before the DELE command is sent to delete the message just received.  This suggests the time may be lost, not by my ISP only but by T-Bird.  I have a humongous number of filters, and they could well take "a while" to execute.  Needless to say, that shouldn't cause the connection to be timed-out even if it required NOOP messages to be sent.

	Magnus Melin [:mkmelin]
	Comment 3 • 17 years ago

That that bug was filed a long time ago doesn't mean this isn't a dupe, that bug just never got fixed. I still don't see any real difference, and the 10s of dupes of the other bug looks very similar to this too.

	David A. Cobb Reporter
	Comment 4 • 17 years ago

FWIW, I can now add some puzzling information concerning the timeouts that I am experiencing.

If I manually request "Get Messages ..." the status bar shows progress and the connection times out -- sooner or later -- each and every time.

If, however, I do nothing manually and wait until the timer "check for mail every (10) minutes" triggers the download, then:
(a) The status bar doesn't show anything; and
(b) If the connection times out at all, it restarts itself without intervention.

If the network were truly timing out because the ISP is failing to respond, then I would expect the timeout to occur:
(a) Following an RETR, and sometime before the message is complete; or
(b) Following a DELE command or some other that solicits a +OK or -ERR message in return.

Neither is the case here.

	zug_treno
	Comment 5 • 16 years ago

(In reply to comment #0)
> The program should wait a few minutes and attempt to re-establish the
> connection.

Related to bug 371922 and/or Core bug 82999?

	David A. Cobb Reporter
	Comment 6 • 16 years ago

Likely related to Bug 371922.
Bug 82999 -- I don't think so.  In fact, that one should be verified; as long as I don't ASK to download messages, i.e. I wait until the "Check every 10 minutes" expires, the program DOES start again.  Of course, it then wastes time running through the list of messages that were downloaded before the timeout and DELE`ting them (again).  Hey! at least they aren't downloaded again.

After a little more thought, what the program "should" do is send a STAT.  If there is no reply then wait, if the server responds to STAT, then go back to what you were doing before the timeout.

	Wayne Mery (:wsmwk)
	Comment 7 • 15 years ago

David, Since you are currently running trunk, how is this behaving?

	David A. Cobb Reporter
	Comment 8 • 15 years ago

I can't easily tell how this is behaving now.  It became so disruptive that I set up to use "fetchmail" to collect my messages.  It does that in just a few minutes, even after a weekend's pile up -- because it doesn't do anything else.  Then Thunderbird picks up the mail with the Movemail service.

My experience convinces me that the solution to this, and perhaps other problems, is to split the "Get Mail" process:
1)  Connect to the POP server;
2)  Download all (or some large number of) messages;
3)  Don't do any further processing, except perhaps to avoid duplication -- park the messages somewhere in a TEMP mbox;
4)  Drop the connection;
5)  Now, with the messages in a local file that's totally under Thunderbird's control, filter them or whatever.

That would be a BIG change!  :-(  And big changes are likely to be won't-fixed.

HOWEVER, that is only one way to "recover from network timeout."  I'm afraid someone else who can allow a suitably huge backlog build up will have to check it out.

	Wayne Mery (:wsmwk)
	Comment 9 • 14 years ago

duping to bug 371922 which should probably go to some networking component  Which needs detail like someone running v3.1 and appropriate logs. The original report in comment 0 is of course bug 123440.