Closed Bug 92072 Opened 23 years ago Closed 20 years ago

Courier-IMAP: Number of IMAP connections open is not limited

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 71792

People

(Reporter: mozilla, Assigned: mscott)

References

Details

(Keywords: imap-interop, perf) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2+) Gecko/20010723
BuildID:    2001072303

During normal operation, Mozilla seems to open more and more IMAP connections to
the same server. My default courier-IMAP installation limited me to 4
connections/IP, which caused a "server refused connection" error to pop up.
After raising that to 6, I still get the same message.

This error may be related to 87825

Reproducible: Always
Steps to Reproduce:
1.Define an IMAP account to a server running courier-imap in default config.
2.Define several folders
3.switch between them.

Alternatively
1. Define several IMAP accounts to the same server running courier-IMAP.
2. Switch between them.


Actual Results:  An error message saying "The server refused connection" poped
up on some of the folders (it seems that once a certain folder uses a certain
folder, that folder will continue to work).

Expected Results:  I should be able to use an IMAP client with one connection only.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Problem also happens under Linux 
BuildID:  2001082606 

Playing around with IMAP, opening a few folder, having "check for new messages
on", etc, it doesn't take long to get "connection refused" messages when the
IMAP server (Courier-IMAP in this case) starts rejecting new connections because
you have the maximum allowed 4 open.

tcp        0      0 194.100.xx.85:1428      194.100.xx.82:993       ESTABLISHED 
tcp        0      0 194.100.xx.85:1432      194.100.xx.82:993       ESTABLISHED 
tcp        0      0 194.100.xx.85:1433      194.100.xx.82:993       ESTABLISHED 
tcp        0      0 194.100.xx.85:1434      194.100.xx.82:993       ESTABLISHED 

(IMAP-over-SSL in this example).


For more details see the original bug report.
Using 0.9.4 under Linux and Windows, I was able to open 10 or more folders on a
Courier-IMAP server (version 1.3.11) and the number of connections reported by
the server topped out at 5. This seems consistent with my reading of
mailnews/imap/src/nsImapIncomingServer.cpp -- in the CreateImapConnection
method, maxConnections defaults to a hard-coded value of 5.

Courier-IMAP does indeed default to a maximum of 4 connections per IP, so in the
default case this'll cause problems for mozilla users with multiple folders.

It also looks like there's a per-server preference to control this
("max_cached_connections"), but you probably have to edit your prefs file
manually to set this.
I have this problem on the 10/1 MacOS 9.x build as well. Beefing up Courier-imap
to handle a lot more connections solved the problem although it seems to be bad
form for Mozilla to be so connection hungry. Combined with bug 87825 (related?),
this does beat up on Mail's IMAP usefulness.

I was testing this out on N4.7, and it played well with my Courier-IMAP server
at its default setting.
Keywords: interop
Summary: Number of IMAP connections open is not limited → Courier-IMAP: Number of IMAP connections open is not limited
as a server writer, i don't find 5 concurrent connections to an IMAP server all
that outrageous, especially since each new connection may incur a new TLS
negotiation (hopefully session resumption, but who knows) and a possibly
expensive authentication.

i think the default courier limit is really a little silly.
OK, Courier imap only allows by default 4 connections from
any IP address (or 40 in total from any IP). Now mozilla makes
5 connections by default. This isn't so bad if Mozilla noticed
the connection refused and just used its existing connections.
But what does it do!...

When it tries to connect the 5th (the 5th folder browsed)
courier immediately closes the connection and it seems
mozilla just sits there like a muppet waiting for data
on the closed socket.

(There is a full connection establishment and teardown,
i.e.
============================
Mozzie             courier
============================
Syn---------------->
   <--------------- Syn, Ack
Ack---------------->
           :
    31 microseconds
           :
   <--------------- Fin, Ack
Fin, Ack----------->
   <--------------- Ack

So mozzie has returned from connect()
and is doing a read() which should return 0.
However Mozzie seems to continue to try and 
read (forever) from this closed socket.
)
                   
From this point on you can not browse
any new folders (you can browse 4 first folders you opened
as these connections are still OK). I.E. you need
to restart mozilla to get to other folders.

Note a handy way to see the connections from
mozzie is: watch -n1 'netstat -tan | grep 143'

My build ID is 2001112012 (on Linux).
I agree with Chad_House, where he says:

<quote>" It also looks like there's a per-server preference to control this
("max_cached_connections"), but you probably have to edit your prefs file
manually to set this."</quote> 

However, when mozilla finds the server rejecting the Nth connection, it should
auto-adjust back and reuse the avaialbe connections if possible. The current
behaviour, as described by Padraig@AnteFacto.com doesn't particularly help. 

This is NOT Courier specific, of course ;)

Using 0.9.9 under Linux and Windows, Courier-IMAP server (version 1.4.3).

Setting courier to 5 rather than 4 connections per IP allows connections to more
than 5 folders (using a single account) , but if you have try to access folders
in multiple accounts you seem to be limited to the first 5 or 6 folders again.
If this  means having to raise courier's connections per IP setting to (5 * # of
accounts), on a shared PC this could be a large number.

Going offline and online again resets the situation.
*** Bug 112692 has been marked as a duplicate of this bug. ***
QA Contact: huang → meehansqa
Just noticed 71792 fixed today,
which basically gives a configuration
option for number of connections to "cache".

I think this bug is a dup of it?
I'm still having this problem in 1.0:

Using multiple accounts:

Moving messages around in uw-imap, and Exchange imap works fine, but when I move
a message in my courier imap, I can't see the result.  Ex:

Move message from Inbox --> Shared.notices.alerts 

I have to go offline and then online again before I can see the message in
alerts (it does get moved)
Bug persists in Mozilla 1.1-final. Still getting disconnects from Courier-IMAP
because Mozilla has too many connections open and does not recycle them.

Is there a leak somewhere?
Why do Mozilla need to open several simultaneous sessions at all? I have a lot
of mailboxes I wish to monitor for new mail, and this behaviour increases the
server a lot.

I would be very glad to hear why Mozilla does this! Can perhaps IMAP IDLE help?
Or does it need fixing?
*** Bug 89583 has been marked as a duplicate of this bug. ***
This bug seems to persist in 1.2 beta.

I still have to use the online/offline trick to view CourierImap folders if I
view too many folder in one session.
is the situation still the same with a newer build? (bug cleaning)
I don't think this bug is an issue anymore ... now that you can limit the number
of connections in your preferences it really isn't an issue with Mozilla but
with IMAP servers that don't handle requests for connections over their limit in
a responsible manner (e.g. Courier-IMAP).  It doesn't seem like the number of
accounts affects the number of connections opened anymore.  Though maybe people
want to keep it open to address a specific issue.  In that case it should
probably be retitled to reflect what that issue is.  I'm using 1.4rc1 with
mulitple accounts I am able to open a series of folders and copy back and forth
between different accounts.  I'm using Exchange 5.5 and Courier-IMAP, both of
which seemed to cause problems previously.
dup of 71792 - you can limit the number of connections we'll cache (though we
limit the low number to two - instead, we should probably limit it to 1)

*** This bug has been marked as a duplicate of 71792 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.