On Mon, Jul 25, 2005 at 10:56:38AM -0400, Geo Carncross wrote:
> I understand what you're saying about duplicates now. You're saying,
> worst case scenario, UID 6 is downloaded twice- once as UID 6 and
> the second time as UID 9.
Yes. In particular, we can't cheat the gods of mathematics -- we're
still subject to race conditions. Just, instead of a race condition
resulting in lost mail, it results in an email being read under two
different UIDs. The worst case is duplication rather than lost mail.
> Note: "B" however cannot ignore that message. It _MUST_ rewrite
> it. It's not acceptable for UID 6 to refer to a different message on
> each host. After that replication, a request for UID 6 must fail.
No; my terminology ("email" vs. "message") may be confusing here. The
switch from UID 6 to UID 9 for that email is accomplished
automatically, by DB replication; B has no choice or even knowledge of
it. After it happens, B has an email with UID 9 and no email with UID
6 whether B likes it or not. The message from A to B after A
reassigns UID from 6 to 9 is going a step farther; it's saying "A
created UID 9, so B, if the user has read an email with UID 10 or
later, please go ahead and reassign the UID for email UID 9 to
something still higher (ie. 11)." Ie. we need to allow for the
possibility that the scheme will need to be executed multiple times
for a single email. B can ignore that message if the user hasn't
downloaded an email with UID 10 or later. If the user has downloaded
a higher UID from B in the meantime, B needs to go ahead and assign a
new UID to the email, etc.
> Also note that this lowers the effective number of messages per
> mailbox pretty quickly. a UIDVALIDITY change could be needed as
> quickly as 1.5 million messages on a 64-node dbmail cluster. I have
> a few mailboxes that large. A two-node dbmail would be sufficient
> for most, and "only" support about half a billion messages. Someone
> with a billion messages can suffer if they're using IMAP still...
True. Although you might still mix read-write and read-only servers,
ie. in a 64-node cluster, you might have two or four masters
(read-write), and make the rest read-only. The scheme would only need
to be applied to master servers, so the 32-bit problem would only be
spread across your master servers, not across all servers.
> The good news is that this system is a lot simpler than your
> mechanism. You can implement it as an IMAP client and DBMAIL needs
> to know nothing about it (except one point!)
[snip]
I'm not sure I get this, but I'll take your word on it.
> That said, I think I like this idea.
Cool beans.
> It's less invasive than mine, but I think this will screw up several
> clients. The question would be "how bad". I'm betting the worst
> would be Outlook Express....
Frankly, you know a lot more about IMAP and IMAP clients than I do; a
fair amount of what I know came from reading your old posts. What
would be the problem with Outlook Express?
- Morty
