71792 - IMAP Courier - if we exceed number of connections allowed for our IP address, subsequent connection attempts fail silently.

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Zacharias J. Beckman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; 0.8) Gecko/20010215
BuildID:    2001021503

Mozilla seems to permanently disconnect/develop problems with an IMAP mailserver
and cannot reconnect until all Mozilla windows are closed (ie. quit the entire
application) and it is restarted. The problem only occurs with Mozilla (as
opposed to other clients: I've tried Outlook, Postilion and other IMAP
clients--it's definitely only Mozilla). I've also tried two different IMAP
servers (one from RedHat, another, 'courier-imap'). The results are the same.

The problem appears to be specifically tied to the root IMAP folder, in my case
my 'Inbox'. However, I can switch to other IMAP folders and use them... it is
only my root-level 'Inbox' that becomes unusable.

Steps to reproduce:
1. Open a Mail window and connect to an IMAP server
2. Wait a while (usually about 10 minutes)
3. Next automatic header fetch fails

This could potentially be a timeout problem. I'm not sure, but fairly certain
that our firewall implements various timeout mechanisms.

The specific error panel that appears is:
ALERT
The current command did not succeed. The mail server responded: Error in IMAP
command received by server.

If I close this panel, it will reappear in about one minute (my header fetch
period, I believe). Mozilla is completely unable to talk with the IMAP
root-level folder until I quit/close _all_ Mozilla windows (not just Mail) and
restart. That is, no new mail appears, I cannot open existing mail, etc.
However, I _can_ do these things in _other_ subfolders.

The logs on the server do not show anything particularly useful. There is a
LOGIN event, but no apparent errors.

Reproducible: Always
Steps to Reproduce:
1. Open an IMAP mailbox
2. "Wait" on the root level folder

Actual Results:  Error panel: "The current command did not succeed. The mail
server responded: Error in IMAP command received by server."

Expected Results:  Everything should keep working. New mail should appear.

If I point Mail at a different IMAP folder, the error messages stop coming. I
would guess this is because Mozilla is only checking the _current_ folder,
periodically, for new mail (I wish it would check all folders). But, when I
re-open the root level folder, the error messages _usually_ start to appear
again: one immediately, and then about one every minute thereafter.

However, at some interval I have been unable to comprehend yet, Mail does begin
to show new messages in the root folder, and it does give me access to the root
again. Overall, it's quite confusing...

Comment 1

[Zacharias J. Beckman]

Additional information found in the Courier-IMAP FAQ:

Clicking on "Get new messages" results in an error message "Error in IMAP
command received by server", or nothing happens at all when I know there are new
messages in a shared folder. ANSWER: this is a known bug in Messenger's IMAP
client. Complain to Netscape. You can try reinstalling Courier-IMAP with the
--enable-workarounds-for-imap-client-bugs

Comment 2

[Keyser Sose]

Quite possibly a dupe of bug 60360. Thoughts?

Comment 3

[Zacharias J. Beckman]

This strikes me as possibly related, but the symptoms seem somewhat different. 
Most significantly, my observation is that Mozilla works fine for "a while," 
then starts to develop problems. I've also seen a few situations where the 
problem downloading new messages "goes away," although only temporarily. My 
best guess is that it doesn't deal with timeouts or disconnects, although I 
could obviously be way off on this.

If a test account would be helpful, I can configure one. We're using Courier 
IMAP these days (although the problem also existed with our previous IMAP 
server). Just email me with a request for an account, and I'll get it set up 
([e-mail]).

Comment 4

[Keyser Sose]

Marking NEW.

Comment 5

[Tom Mraz]

How many simultaneous connections do you have allowed from one client? And how
many total processes in the courier IMAP setup? 
I've found that if you have sim. connections < 5 per 1 Mozilla client and total
processes 5*clients that Mozilla often hangs as you described.
It's certainly Mozilla's fault that it doesn't have reasonable reusage and
expiration of unused IMAP connections but it seems to me it can be easily
workarounded this way.
 

Comment 6

[David :Bienvenu]

my guess is a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=103401

generating a protocol log would help tell:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 7

[Tom Mraz]

No, that's a different bug. On Courier IMAP you can set arbitrarily low limit on
number of simultaneous connections from one client machine. It seems to me that
Mozilla doesn't like if it can't make less than 5 connections to IMAP server
when you browse through folders.
If you don't allow it in the Courier IMAP setup then the Mozilla gets stuck and
it doesn't reuse the old connections and doesn't close them so the throbber
animates but no email download happens anymore.

Comment 8

[njvack]

I had luck with reconfiguring Courier.
In /etc/imapd:
Change MAXDAEMONS to a bigger number (I'm happy with 100)
Change MAXPERIP to a bigger number (I'm happy with 20)

I pulled these numbers off some courier support list; YMMV.

Comment 9

[Hans Deragon]

I confirm the comment #8 of [e-mail].  I have set MAXPERIP to 6
and things are working fine.

I believe that Mozilla should be an example of a good, easy going IMAP client
and thus should use less connections if the design permits.  Also, when Mozilla
is stuck, it should not hang indefinitly.  A timeout of 10s should be enough,
and an error message should appear after explaining that the IMAP server does
not offer enough connections per client and that for example on Courier,
MAXPERIP should be set to more than 5 (I like it when error messages provide the
solution; I prefer to have it in my face than having to search a faq or some
newsgroup).

Comment 10

[David :Bienvenu]

a protocol log would still help here, or access to a server with such a
limitation (if anyone has such a server outside a firewall that they'd let me
try with a test account for a day or so, I could look into this).  Does the
server return an error, or just spin and wait/silently fail? I'm surprised that
we don't pass on an error to the user if we get one. Yes, you're right that we
should handle the case of the Nth connection failing, though we're unlikely to
put special cases in the code or error messages referring to particular imap
servers.

Comment 11

[Hans Deragon]

No clue how to get a protocol log out of Courier.  As for access to a test
account, I tried to set one out, but I could not reproduce the problem with my
test account!  My test account is a subset of my personnal emails, and with 5
connections set as the maximum in Courier, it works fine.

However, with all of my personal email, it does fail.  Mozilla spins
indefinitly, until one press the "stop" button.  Since my personal email is,
well, personal, I cannot give you that account for testing. :(

I'll see what I can come up with.  Stay tuned.

Comment 12

[David :Bienvenu]

a client side protocol log:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 13

[David :Bienvenu]

I'm using Hans' test account now - what I see is the connection failing
silently, but there's no meteors spinning - just silent failure clicking on
folders or messages after the four connections have been used up. It's possible
if the dns lookup takes more than half a second, I suppose the meteors could
start and not stop. The imap code is not getting any kind of error back from
necko - we just get a ::OnStopRequest notification with a status of 0 (success).
I can try to come up with an error message for the case where we get an
OnStopRequest with no error but we've not been able to make contact with the
server at all (from our point of view). It may, however, be impossible for the
imap code to distinguish this from the user pressing STOP because a connection
took too long to open (which also results in OnStopRequest w/o an error)

Comment 14

[David :Bienvenu]

I have a proposal for this, far from perfect, but basically, we don't have
anything close to perfect information (i.e., that the server reached a
connection limit) which would allow the perfect solution. My proposal is this:

1. Expose the max number of per-server cached connections as an advanced imap
server pref. The current default is 5. The UI would be something like a text
entry field with the label "Cache at most XX connections".

2. If we get an ::OnStopRequest with a success status on an nsImapProtocol
without ever having seen the server greeting, then we put up an error message
something like: "Your IMAP server appears to have refused the connection. It is
possible that you have exceeded the maximum number of connections to this
server. Lowering the maximum number of connections the client will cache might
help. This setting is on the Advanced IMAP Server settings dialog. 

Jennifer, can you help with the wording on the dialog and the wording for the
error message? I know this is advanced stuff but basically, what's happening is
that the client will cache open connections to the imap server, by default, 5,
and some personal IMAP servers by default only allow 4 connections total.
Unfortunately, we don't get any kind of error from the server; it just fails
silently.

Comment 15

[Henry Jia]

CC'ing to myself

Comment 16

[jglick]

Is this something only more advanced users will run into? How often do you think 
average users will encounter this? If its something only advanced users will 
see, the Alert is probably ok, or advanced users would be able to edit a hidden 
pref. It sounds like we might show this Alert in cases where we aren't really 
sure what the problem is? I'd hate to see average users get this Alert since 
they won't understand it.

If it needs to be visible in the UI, I'd suggest: 

"Unable to connect to your IMAP server. You may have exceeded the maximum number 
of connections to this server. Use the Advanced IMAP Server Settings dialog to 
reduce the number of cached connections."

Comment 17

[David :Bienvenu]

definitely only advanced users, because I think only users who set up their own
Courier imap server will see this. I don't *think* normal users would see this
message, though I need to run with it for a while to be sure. I agree that it
would not be acceptable for normal users to see this message. However, it's
pretty bad that we don't show any error message in this situation now.

There are other reasons to make the pref visible to control the number of
connections we cache - users might want to change that value for other reasons.

Comment 18

[jglick]

If its something only advanced users may run into, i'm ok with the additional 
checkbox and Alert.

Comment 19

[Hans Deragon]

Question:  Do 5 connections provide much improvement?  What if by default,
Mozilla opened only 4?  It seams that all other IMAP clients open less connections.

Or, we could talk to Courier developer and ask that Courier come with a default
maximum of 5 connections per client, instead of 4.

My point is that it would be great that an out-of-the-box Mozilla would work
without configuration changes with an out-of-the-box Courier server.  Lets put a
standard out there for IMAP client and servers so that these values should
actually never be changed by any administrator.

Still, something needs to be done to report the error to the user.

Comment 20

[David :Bienvenu]

We will put up an error message - I've got that working in my tree already. Five
is a nice round number. We used to use 10, and lowered it to 5. I'm not really
inclined to go down even more just for Courier. I think having a UI to set the
number of cached connections is fine.

Comment 21

[Zacharias J. Beckman]

In response to #17: Not only advanced users. We use Courier as our preferred
IMAP server company-wide, across two different companies. All of our users
(well, at least those interested in Mozilla) could be affected... [and we don't
recompile Courier, we use pre-built RPM's]...

Comment 22

[David :Bienvenu]

Right, sorry, it's not just advanced users. But I think having a UI for this is
sufficient - even non-advanced users should be able to change the 5 to a 4,
given the proper instructions.

Comment 23

[Sam Varshavchik]

Re #1, #2: the FAQ was referring to Bug #55126.

Re #17, #21: maximum connection limits are configurable at runtime, and do not
require a custom build.

Comment 24

[David :Bienvenu]

Changing summary and keyword. Taking. Patches upcoming.

Comment 25

[David :Bienvenu]

Attachment: proposed fix

fix as described above.

Comment 26

[David :Bienvenu]

Cavin, can I get a review? thx.

Comment 27

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

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

sr=sspitzer

since you are adding UI, can you provide a screen shot?

Let's get jglick and robinf to review the UI change and the proposed strings so
that they can update the spec.

Comment 28

[Cavin Song]

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

r=cavin.

Comment 29

[David :Bienvenu]

Attachment: screenshot of advanced dialog

Comment 30

[David :Bienvenu]

fix checked-in

Comment 31

[jglick]

Attachment: Minor nit: remove extra separation lines

Comment 32

[David :Bienvenu]

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