Hi all,
Thought I'd bring you up to speed with regard to the state of things to
come. Even though it's been a while since I released 2.3.2, I haven't
excactly been sitting around idly.
- libzdb
Dbmail has has now fully switched to using libzdb for driving the
database layer. It's a beautiful lit
Aaron Stone wrote:
> Just spent some time reading code. Looks awesome! Well done!
Glad you like it.
> What I'm gathering is that at the moment we're still single threaded,
yep.
> but because of libevent, we never have to worry about managing
> non-blocking -- calls to eventbuffer_write never bl
Just spent some time reading code. Looks awesome! Well done!
What I'm gathering is that at the moment we're still single threaded,
but because of libevent, we never have to worry about managing
non-blocking -- calls to eventbuffer_write never block, and
dbmail_imap_session_set_callbacks sets up th
Hi all,
Just sending another little update since I merged the events branch into HEAD
late last night and is on track for 2.3.3.
Apart from being event-driven, I've also refactored the imap code to be much
better at imap compliance. The imaptest tool (imapwiki.org) now passes all tests
except ch
Paul J Stevens wrote:
> I'll do some more tests and will keep you all posted.
After more testing, I've concluded that preforking is a dead-end.
It doesn't solve throughput issues wrt the database backend.
It introduces a lot of problems with synchronizing the forked children which
pollutes the i
Paul J Stevens wrote:
> Simon Gray wrote:
>> Do you have any plans for the db connection pooling as yet?
>
> Sure do. The plan is as follows:
>
> I'm well underway with making dbmail fully event-driven using libevent. This
> will enable dbmail daemons to handle a lot of clients simultaneously on
Paul J Stevens wrote:
Simon Gray wrote:
Do you have any plans for the db connection pooling as yet?
Sure do. The plan is as follows:
I'm well underway with making dbmail fully event-driven using libevent. This
will enable dbmail daemons to handle a lot of clients simultaneously on eac
Simon Gray wrote:
> Do you have any plans for the db connection pooling as yet?
Sure do. The plan is as follows:
I'm well underway with making dbmail fully event-driven using libevent. This
will enable dbmail daemons to handle a lot of clients simultaneously on each
preforked child. When that is
On Wed, 2007-02-07 at 03:34 +0100, Martin Furter wrote:
>
> On Tue, 6 Feb 2007, Aaron Stone wrote:
>
> >
> > Hey folks, I've updated the multifoo architecture page on the wiki to
> > reflect some of my latest work on the subject. At this point I'm starting
> > to build the framework for the threa
On Tue, 6 Feb 2007, Aaron Stone wrote:
Hey folks, I've updated the multifoo architecture page on the wiki to
reflect some of my latest work on the subject. At this point I'm starting
to build the framework for the threaded server core. I think I've
eliminated the need for a thread pool librar
On Tue, Feb 6, 2007, Leif Jackson <[EMAIL PROTECTED]> said:
> On Tue, February 6, 2007 3:35 pm, Aaron Stone wrote:
>> On Tue, Feb 6, 2007, Aaron Stone <[EMAIL PROTECTED]> said:
>>> eliminated the need for a thread pool library and for any super
>>
>> Sorry, I *do* need a thread pool library -- I'
On Tue, Feb 6, 2007, Leif Jackson <[EMAIL PROTECTED]> said:
> Aaron,
>
> From your wiki page:
>
>>On the issue of a database connection pool, I think that issue is mooted
> by >this architecture. There are relatively few commands that do not
> require >any database interaction, and the ones tha
On Tue, February 6, 2007 3:35 pm, Aaron Stone wrote:
> On Tue, Feb 6, 2007, Aaron Stone <[EMAIL PROTECTED]> said:
>
>
> [snip]
>
>> eliminated the need for a thread pool library and for any super
>
> Sorry, I *do* need a thread pool library -- I'm going to use Glib's. I
> won't need a database pool
Aaron,
From your wiki page:
>On the issue of a database connection pool, I think that issue is mooted
by >this architecture. There are relatively few commands that do not
require >any database interaction, and the ones that dont are so fast to
process as >to not warrant the additional abstracti
On Tue, Feb 6, 2007, Aaron Stone <[EMAIL PROTECTED]> said:
[snip]
> eliminated the need for a thread pool library and for any super
Sorry, I *do* need a thread pool library -- I'm going to use Glib's. I
won't need a database pool library; each thread will own its own database
handle directly.
Aa
Hey folks, I've updated the multifoo architecture page on the wiki to
reflect some of my latest work on the subject. At this point I'm starting
to build the framework for the threaded server core. I think I've
eliminated the need for a thread pool library and for any super
complicated back and for
Aaron Stone wrote:
http://www.dbmail.org/dokuwiki/doku.php?id=multifoo_architecture
^
On Wed, 2006-10-25 at 02:29 -0700, Aaron Stone wrote:
I want to draw some spare cycles in the backs of people's heads over to
a new page I just set up in the Wi
http://www.dbmail.org/dokuwiki/doku.php?id=multifoo_architecture
^
On Wed, 2006-10-25 at 02:29 -0700, Aaron Stone wrote:
> I want to draw some spare cycles in the backs of people's heads over to
> a new page I just set up in the Wiki:
> http://www.dbma
I want to draw some spare cycles in the backs of people's heads over to
a new page I just set up in the Wiki:
http://www.dbmail.org/dokuwiki/doku.php?id=mulifoo_architecture
What I want to do here is nail down a design for multiplex, multithread
and multiprocess operation to ramp up DBMail's scala
19 matches
Mail list logo
