Zimbra closing active IMAP connections

[gharris@metacarta.com]

Hi,

I'm having a problem attempting to move a large mailbox from one Zimbra server to another (ZCS 5.0.9) using imapsync. The imapsync appears to be failing on the same message (a large file) on every attempt.

I believe from the below logs that the Zimbra SessionCache is timing out the session because it has seen no new commands even though the Zimbra IMAP library is continuing to transfer data...

2009-07-24 11:04:09,288 INFO  [Timer-3] [] SessionCache - Removed 1 idle sessions (IMAP). 34 active sessions remain.
2009-07-24 11:04:09,307 INFO  [ImapSSLServer-27510] [] ProtocolHandler - Exception occurred while handling connection
java.net.SocketException: Socket is closed
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1223)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1244)
        at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:43)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
        at com.zimbra.cs.imap.ImapHandler.fetch(ImapHandler.java:3065)
        at com.zimbra.cs.imap.ImapHandler.doFETCH(ImapHandler.java:2872)
        at com.zimbra.cs.imap.ImapHandler.executeRequest(ImapHandler.java:423)
        at com.zimbra.cs.imap.TcpImapHandler.processCommand(TcpImapHandler.java:124)
        at com.zimbra.cs.tcpserver.ProtocolHandler.processConnection(ProtocolHandler.java:160)
        at com.zimbra.cs.tcpserver.ProtocolHandler.run(ProtocolHandler.java:128)
        at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:595)

I have run imapsync in debug mode and the server is clearly continuing to transfer the message until the socket is closed by the SessionCache underneath it.

Does anyone know of any variables that I can tweak to extend the session cache timeout for IMAP connections?

Thanks,
-- Greg

[gharris@metacarta.com]

I spent a bit more time digging through Zimbra code and I've come to believe that this may be a bug. I will file shortly unless anyone disagrees.

Here are the two problems I found:

1. The Imap idle connection timeouts are hard-coded to 30 minutes

From cs/imap/ImapFolder.java

public static final int IMAP_IDLE_TIMEOUT_SEC = 30 * Constants.SECONDS_PER_MINUTE;
public static final long IMAP_IDLE_TIMEOUT_MSEC = IMAP_IDLE_TIMEOUT_SEC * Constants.MILLIS_PER_SECOND;
...
getSessionIdleLifetime() then returns IMAP_IDLE_TIMEOUT_MSEC;

2. The lastAccessed variable on the session is only updated when a new request is received.

From cs/imap/MinaHandler.java

public void requestReceived(MinaRequest req) throws IOException {
...
if (i4selected != null)
    i4selected.updateAccessTime();
...

If an underway request is not finished before the 30 minutes timeout the session will be expired by the SessionCache manager.

From the documentation of SessionCache in cs/session/SessionCache.java:

    /** Adds a {@link Session} to the cache and assigns it a session ID if it
     *  doesn't already have one.  When a reigistered <code>Session</code> ages
     *  out of the cache due to extended idle time, its {@link Session#doCleanup()}
     *  method is invoked and its session ID is unset.
     * @param session  The <code>Session</code> to add to the cache
     * @return the session ID assigned to the Session
     * @see Session#getSessionIdleLifetime() */

I believe that I'm running into a problem where I have a very large message that is taking longer than 30 minutes to transfer. Since the Imap client does not make any new requests in those 30 minutes (its still processing its last request) the SessionCache manager expires its session which causes the connection to get closed which results in the traceback from my original post.

-- Greg

[marcusg]

I'm having the same issue, only it's because the user has so many folders while imapsync is calculating the folders zimbra times out and it all dies from there.

Did you ever open a bug for this?
If so where?

Did it ever get resolved?
If so how?

[FritzBrause]

you may try imapsync with the following options:

–-nofoldersizes –-useheader Message-ID –-fast

This will prevent timeouts in most cases unless mailboxes are really huge.

The problem is not the Zimbra IMAP Timeout value but imapsync calculation of folder- and messagesizes.