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