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@xxxxxxxxxxxxx
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
