sync_client bails out after 3 MAILBOXES need upgrading to USER
in one run
David Carter
dpc22 at cam.ac.uk
Tue Aug 29 04:35:32 EDT 2006
On Sun, 27 Aug 2006, Bron Gondwana wrote:
> I've attached my trivial solution (against CVS of last week some time),
> but I'm thinking a better (as in, less wasteful) solution might be to
> not return an error at all for a failed mailbox, but instead keep
> walking the entire tree, and then generate a "USER" event for every
> mailbox that hasn't been marked yet.
My original code (which we are still running: I'm not in any hurry to
upgrade to 2.3) sorts mailbox actions by user. If a single mailbox action
associated with a user fails the rest are discarded and a USER event is
generated. If the USER event fails it locks the given user out of the
mboxlist and tries again. This is close to what you describe above.
>From memory the 3 retries thing was introduced to cope with transient
problems on shared mailboxes, caused by mailboxes moving around under the
replication engines feet. No promotion is possible in this case.
> Ken and David - is there a reason why you chose to pass a single
> "MAILBOXES" command with multiple mailboxes to the backend rather than
> single mailbox commands? The little birdy in my head is whispering (it
> does that at 1am after many hours of debugging) that it has something to
> do with supporting renames.
Rename and copying messages between mailboxes. With single mailbox
commands RENAME becomes DELETE + CREATE/UPLOAD (which would work, but
would be a pain if a GByte mailbox was involved). COPY would upload new
messages rather than reusing the single instance store on the replica.
--
David Carter Email: David.Carter at ucs.cam.ac.uk
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
More information about the Info-cyrus
mailing list