243570 - on occasion, IMAP access runs until timeout

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[John Belmonte]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Build Identifier: version 0.6 (20040502)

Sometimes an IMAP access will just spin on and on, until a timeout finally 
occurs 5 or 10 minutes later.  This can happen either when I do a "get new 
messages", or when I go to a folder that has pending headers to download.  
While this is occurring, "stop current transfer" requests are ignored.  My 
only choices are to wait until the timeout, or to restart Thunderbird.  After 
a restart, IMAP access is always fine, so it is not the case that the server 
was unavailable. 
 
My IMAP server is courier-mta. 
 
I've been using Thunderbird for a long time (at least since version 0.4), and 
this bug has always existed.  It happens to me several times a day. 
 

Reproducible: Always
Steps to Reproduce:
 
Actual Results:  
 

Expected Results:

Comment 1

[Gayle]

I get the same on Windows.  My initial suspicion was that it was a server
problem (I set it up so always a possibility) but Outlook doesn't display the
same problem.  Going offline then online sorts it out.

TB stops at "connected to host.domain.tld" and there's nothing in the
/var/log/mail.log to show anything untoward.

IMAP server is courier-imap with SSL.

Comment 2

[Gayle]

I know what caused my problem, may or may not be the same for you.  Every time
TB goes to a new folder it creates a new connection and the old connection is
left open as well (presumably to allow new mail notification).

In my case I have quite a few folders and was exceeding the maximum allowed
connections per IP limit on my server.  I've upped this limit and now the
problem has gone away.

As far as I am aware there is no defined way for the server to pass back this
error to the client, with courier-imap I see a few SYN/ACK/FIN packets going
back and forth but that's it.

It seems this is not a bug in Thunderbird but the IMAP implementation could
possibly be cleaner, I have a suggestion for a better way of doing things but am
going to post on the forums before submitting it to Bugzilla as it may be
completely unworkable and I'd like to see some discussion first.

Comment 3

[John Belmonte]

I'm not convinced that my problem is the same.  In Thunderbird, I have "max 
number of server connections to cache" set to 5.  In /etc/courier/imapd, I 
have MAXDAEMONS and MAXPERIP set to 40.  In imapd-ssl, I don't have any 
setting for these, as I assume they are inherited from imapd (am I correct?). 
 

Comment 4

[John Belmonte]

Note that the release notes for 0.7 say "Fix for an occassional hang when 
reading IMAP mail over SSL".  I'm switching to the latest version today and 
will report. 
 

Comment 5

[Adam Becevello]

John,

You didn't reply on the status of this with 0.7.  Did the newer version solve
the problem?  If not, you could try 0.9 or 1.0RC1 to see if they fixed the problem.

Please report back on your findings.

Comment 6

[John Belmonte]

I think I tested 0.7 and it didn't help. 
 
I noticed that although I had the courier server MAXDAEMONS and MAXPERIP set 
to a high number, the number of authentication daemons was still set to only 
5.  So in Thunderbird I reduced the IMAP "max number of connections to cache" 
to 3 and haven't really seen the problem since.  So perhaps this wasn't a 
Thunderbird issue. 
 

Comment 7

[Adam Becevello]

John,

Would you be fine if this bug were resolved since it looks like it may have been
a server problem?

Comment 8

[John Belmonte]

Ok to close this bug... but I do think Thunderbird should offer more sane 
behavior for cancelling a connection attempt.  As I explained, the stop button 
didn't have any affect, and I had to wait several minutes for the timeout or 
restart Thunderbird. 
 

Comment 9

[Adam Becevello]

John,

Feel free to file a new bug about cancelling a connection attempt.

I am going to resolve this bug as invalid since it wasn't a bug in thunderbird.