Currently dbmail preforks, where each child maintains a separate database connection. The number of preforks is mostly determined by the database backend, and how many connections it will allow.
This won't scale too well because each incoming connection will use up a database connection, even if no database interaction is actually required (idle imap connects). I'm therefor working on a different setup: dynamically preforked server, with descriptor passing. The idea is that a single master process listens for incoming connections, and reads the commands for all connected clients. Once a command is read, the client socket and the command string are passed to an idle child in the process pool, receiving back the socket from the child after it is done with the command. In such a setup, preforked children are always busy handling commands, where the master process handles incoming connections. This would allow us to keep the number of preforked children lower, while being able to handle a *lot* more clients. This is all still very much in a prototyping stage. Passing file descriptors (sockets) to preforked children is kind of tricky, or well I'm new at it anyway. I wouldn't have guessed it was possible hadn't Geo hinted at it, or I found an explanation in W. Richard Stevens': Unix Network Programming; vol 1. gopalakrishnan kamalanathan wrote: > Hi, > > Does DBMail maintains a pool of database connection and use that or does > it make a new connection for each session? > If it has a pool of connections what is the maximum number of > connections that is maintains? > > Thanks. > Krishna > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
