On Fri, Jul 22, 2005 at 02:27:24PM -0400, Geo Carncross wrote: > If you have per-user host affinities that are _guaranteed_ then > you've gotten load-balancing (again) and not > high-availability. You've just moved the load-balancing onto an > extra point of failure.
No, you have high availability, too. Load balancers do NOT guarantee user affinities; in particular, if a server goes down, the users for that server are remapped to other servers. But affinities aren't really necessary for the basic scheme to work, anyway. They're an additional detail that isn't necessary to solving the basic problem, but are useful towards mitigating a secondary problem. So for now, please ignore everything I'm saying about duplicates and affinities. Please concentrate on the message passing, UID modification, and basic problem of not losing email on a multimaster IMAP setup. > Nevertheless the problem still exists: > Client is fresh > Client connects to A and gets UID 1,2,3,4,5,7 > Client connects to B and sees EXISTS=6 > because B sees UID 1,2,3,4,6,7 > Client will NEVER download "UID 6" because it doesn't know about it. No. *Initially*, server B has a message with UID 6 which the client won't download. But replication keeps going. The email with UID 6 is replicated to A. The message from B to A saying it created UID 6 is replicated to A. So Server A learns about UID 6. Then this scheme kicks in: server A says "oops, I didn't know about a UID 6 when the client downloaded 7", and reassigns the email a new UID -- say, UID 9. That change, in turn, is replicated back to B, along with a message that says A created 9. B has the UID 9 email, and can ignore the message if the client hasn't downloaded any newer emails. Next time the client connects to either A or B, the client sees a new UID (9). So the email, originally UID 6, is not lost, it's just assigned a new UID. > No the email is lost because the client "thinks" the highest UID is > "7" but now connects to a machine where UID "6" is no longer a gap. Eventually, all systems adjust and UID 6 really is a gap; the message that was at UID 6 gets assigned a new number that is beyond 7. There may well be a short time when the email with UID 6 isn't available to the user, but eventually, the scheme adjusts. - Morty
