On Thu, Feb 1, 2007, Jesse Norell <[EMAIL PROTECTED]> said: > I think Paul was talking about between dbmail processes on multiple > machines. Eg. You have 2 physical machines providing imap to a shared
Clustering is a separate goal, but if we do clustering, we can use that as our IPC mechanism for IMAP unilateral server side updates mostly for free. > database backend. I don't know anything at all about memcached, but I'm > guessing it's only for processes on a single system, so may have some > benefits for specific installations, but can't be the solution to the > problem as many sites have multiple dbmail servers running (you'd have > to track changes in the database itsself, or come up with some other > plan). You should read up on memcached, as you've got it mostly backwards. :-P > Perhaps combining the two approaches could work? Eg. you track > changes in the database so all dbmail client machines can know about > them, and create a specific thread/process on each dbmail machine that > polls for changes and notifies the actual imap server threads/processes > via memcached. Polling bad. Signaled events good. If the cluster code in dbmail-lmtpd knows to signal dbmail-imapd that a mailbox event has taken place, then if there's dbmail-imapd process/thread/whatever that has registered an interest in that mailbox, it can fire off an IDLE update. Throw memcached into the picture and the dbmail-imapd process can be told by dbmail-lmtpd "Hey, I just updated the INBOX for JoeSchmoe, and the current status is in memcache!" and not a single database query will need to executed on the IMAP side. > On Thu, 2007-02-01 at 23:55 +1100, Jake Anderson wrote: >> Should there be that much need for IPC? >> unless you have shared inboxes why do multiple threads need to deal >> with the same data?, I assume that transfers from a DB backend to an >> IMAP front would be by shared memory and some sort of notify event? Not a safe assumption to make, because the code has yet to be written ;-) You've described one possible model for getting information from database worker threads/processes to the thread/process delivering the response, but there are other models that are just as good. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
