Jan-Henrik Haukeland wrote:
Okay, thanks we'll look into it.
A couple of comments to http://git.dbmail.eu/?p=paul/dbmail;a=shortlog;h=zdb ..
Thanks for taking some time to look at my code. You're quite correct about all those globals. That code branch is very much work in progress. Up until very recently dbmail used a preforking model, with a single connector per process. However, with many concurrent client connections (mostly imap) that model was no longer tennable. So I refactored the server code last month to use libevent within a single process. This scales much better for network io and now the database io then became the main bottleneck.
Ultimately (code complete before the summer) plan is:
- replace the homegrown database modules with a generic layer (libzdb) still using a single connectionpool/connector/resultset etc. That is what I'm working on atm. - next, refactor the database layer to use local connections and result sets, so we can pull a connection from the pool and return it once we're done with it. - finally, start doing the command processing in threads so the database calls don't block the main thread anymore.
I expect and hope that by combining libevent and libzdb we'll achieve quite an interesting potential for scaling up the imap server. Both represent very exciting technologies that fit very well with what I'm trying to do.
After the above milestones have been completed, and if sponsoring is found we might even add multiple connection pools in the mix so different imap users are mapped to different database backends.
- We could add a Connection_vexecuteQuery(T C, const char *sql,
va_list ap) if you want to save those snprintf() calls to build the query and instead call executeQuery directly in the facade function db_query(), or you could skip the facade and call Connection_executeQuery() directly.
Thanks for the offer. I'll give it some thought.
- If you compiled libzdb with exception (highly recommended) you need
to enclose calls that can throw an exception, (basically all methods in Connection, PreparedStatement and ResultSet), in a try-catch statement. Below is an example of a mini-framework we use with libzdb and where we isolate database call and exception testing to a Service function, which may be helpful to take a look at.
I'll make sure the debian packages are build with exceptions and protected. And I definitely plan on leveraging exceptions in dbmail.