I'm taking this to the dev list.... Matthew T. O'Connor wrote: > This sounds scary to me. Obviously it's not my project and I'm not the > one coding, I'm just worried as an admin that depends on DBMail that we > are going to open up a large can of worms for dubious gain.
Matthew, Please be asured, I'm not yet convinced we should go for a threaded model either. Aaron and I started looking for a lib for doing connection pooling to the database. As far as I can tell (http://www.tildeslash.com/libzdb) is the only viable lib which does this. Using such a setup however would require threading. And as everyone keeps telling us, that is no trivial matter. Another option to scale up the database connections would be a worker model where one master process handles all incoming connections using select or libevent or something similar, and hands over clients to one of a limited number of forked workers which maintain the database connections. The worker processes would be very much like the current forked children. The master process would have to do multiplexed IO, and need a callback infrastructure. This approach is actually my favorite since we don't need to make the whole codebase thread safe to do it. It also feels more like an incremental change, rather than a complete redesign of the processing model, which is good imo. So I guess this will come down to one thing only: the one doing the coding gets to be the one who decides this issue. In either case (threading versus workers) the issue of IPC between running dbmail frontends sharing the same backend remains if we want to do IDLE/NOTIFY/etc. Since the database is where they all come together, it'll *have* to be the database where information about changes in mailboxes is shared and exchanged. Caching such information using memcached is just one way to address to performance impact accessing that information will have. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
