This could never happen. The message id is based on the time that it comes in.
If one server goes down, and messages come in while it is down... when it comes back up the messages are all in the timeslot while it was down (ids based on this timeslot) Now any new messages on the server that just came back up are also based on the time... meaning now, so they will go after the messages it is syncing ... A prev message in thread discussed this solution in project. Apparently it works great. The key is computer clocks in sync so the time slots match up, and basing the number on the date/time.. > On Thu, Sep 02, 2004 at 10:13:11AM -0600, Jesse Norell > wrote: >> >> > Example showing message ids that do not collide on two >> > machines using a machine id 001 or 002 received at the >> > same time. >> > >> > - machine 001 msg - received at 2004/09/02 2:10:45:27 >> > - unique_id = 2004090202104527001 >> > >> > - machine 002 msg - received at 2004/09/02 2:10:45:27 >> > - unique_id = 2004090202104527002 >> > >> > >> > >> > In this scenario either machine could go down before >> the >> > message was replicated to the other. When it came back >> up >> > and the synced again it could commit it without >> problems. >> >> I'm not at all familiar with IMAP, would that cause >> any >> problems with imap clients, having "old" unique-id's >> popping >> up at "unexpected" times? Ie. an imap client reads from >> one >> of the disconnected servers and there are a certain >> number of >> messages in the box; the db servers then sync and the >> client >> checks again, finding more messages in the mailbox and >> these >> "new" messages have what appears to be out of sequence >> unique-id's. Sounds like it'd probably be >> rfc-conformant, >> but in practice, will it break client behavior? (I >> don't know >> what imap clients would normally do with the unique-id, >> if they >> save it offline, etc...) > > It sounds like it would be non-rfc compliant since the > unique ids would > not always be increasing. If I get a list of messages > while one > server if disconnected and the max unique id is 1000 and > later when the > disconnected server is reconnected, there are new messages > with unique > ids below 1000, this would likely confuse IMAP clients > that maintain > state on the client side. I'm thinking of offlineimap[1] > in particular, > but other IMAP clients that support an offline mode would > probably have > problems too. > > 1. http://gopher.quux.org:70/devel/offlineimap > > xn > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
