re: (fwd) [Fwd: Communciator 4.02 Imap EXPUNGE problem]

Mark Crispin <MRC@cac.washington.edu> Sun, 24 August 1997 17:26 UTC

Received: from cnri by ietf.org id aa07942; 24 Aug 97 13:26 EDT
Received: from lists2.u.washington.edu (root@lists2.u.washington.edu [140.142.56.1]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA01188 for <ietf-archive@CNRI.Reston.VA.US>; Sun, 24 Aug 1997 13:29:15 -0400 (EDT)
Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id KAA27995; Sun, 24 Aug 1997 10:24:57 -0700
Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with ESMTP id KAA44882 for <imap@lists.u.washington.edu>; Sun, 24 Aug 1997 10:22:41 -0700
Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.04) with ESMTP id KAA27611 for <imap@u.washington.edu>; Sun, 24 Aug 1997 10:22:39 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (clam@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW97.07/8.8.4+UW97.04) with ESMTP id KAA09844 for <imap@cac.washington.edu>; Sun, 24 Aug 1997 10:22:37 -0700
Message-Id: <MailManager.872441535.20177.mrc@Ikkoku-Kan.Panda.COM>
Date: Sun, 24 Aug 1997 09:52:15 -0700
Sender: IMAP-owner@u.washington.edu
Precedence: bulk
From: Mark Crispin <MRC@cac.washington.edu>
To: ccyflai@uxmail.ust.hk
Cc: imap@cac.washington.edu
Subject: re: (fwd) [Fwd: Communciator 4.02 Imap EXPUNGE problem]
In-Reply-To: <199708241258.UAA17679@uststf2>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
X-Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN

On Sun, 24 Aug 1997 20:58:04 +0800, ccyflai@uxmail.ust.hk wrote:
> Actually, the new connection will be
> crashed and return the error messages "IMAP toolkit crash: Lock when
> already lock".

This is older UW imapd behavior.  It tries to save the mailbox state of the
old imapd session, so that any flag settings would be saved.

Communicator's rapid-fire starting of multiple sessions leads to the crash.
The crash is due to a timing race that is lost in rapid-fire sessions.

In the past, the race was usually won because of how it occurred.  Prior to
Communicator, no clients opened multiple sessions to the same mailbox, nor
would anyone think of doing such a bizarre thing.

> I have tried the latest version of UW imapd and found it
> will crash the old connection instead and retain the new connection.

This is current UW imapd behavior.  Unless it is certain that state-saving is
safe, it just kills the old imapd without trying to save the state.  This was
done specifically because of Communicator.

> So,  I think it may be implementation dependent, but I'm sure that they
> all don't support multiple imapd access on the same folder which use
> mbox format.

I don't know of any IMAP server which supports multiple simultaneous access to
UNIX mbox format.  The format simply is not ameniable to such things.

I am very hard-pressed to think of any circumstance with any server in which
the client receives any benefit by opening multiple sessions to the same
mailbox on the same server -- not even when the mailbox format permits such
multiple access.  I can think of many circumstances in which such behavior is
extremely detrimental to the server, and in which such behavior can be
detrimental to the human user.

Communicator should be fixed so that it never opens more than one session to
the same mailbox on the same server.  Even if there were a speed advantage
(which I highly doubt) of the client opening multiple IMAP sessions to the
same mailbox on the same server, it is highly anti-social to do so.

IMAP is not HTTP.  IMAP sessions stay around for much longer than the typical
HTTP session.  Sooner or later, the server system will hit some session limit
and lock out other sessions.