james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [IMAP] MessageRow and MessageFlags
Date Tue, 13 Mar 2007 22:14:52 GMT
robert burrell donkin ha scritto:
> On 3/13/07, Noel J. Bergman <noel@devtech.com> wrote:
>> Robert Burrell Donkin wrote:
>>
>> > Noel J. Bergman wrote:
>> > > Robert Burrell Donkin wrote:
>> > > > the more i look into the model, though, the more i wonder whether
>> > > > achieving good performance won't require changes
>> > > It likely will.  There is a change I want to make, which is to 
>> move the
>> > > message data (the blog) to a separate table.
>>
>> > i don't understand why the message data has to be stored in the
>> > database.
>>
>> Amongst other things, it facilitates clustering.
> 
> i can understand why some people may want to store message data in a 
> database
> 
> what i cannot understand is why JAMES insists that it *has* to be
> stored in a database

I don't think this is true.
We always supported DB, DBFILE  and FILE based repositories.

IMAP instead has its own repositories: it does not use the repositories 
we released in 2.3.0, but the mailboxmanager, that has been written 
specifically for IMAP.

Joachim decided to use Torque for prototyping but this is not a choice 
we made, this was simply the easy step proposed by the developer that 
DID stuff. About IMAP, IIRC, Joachim made it working also using as 
repository the GPL implementation of maildir (file based instead of db).

I see you make many question about IMAP/mailboxmanager stuff: keep in 
mind that all of this is prototype/alpha code and if you have any good 
idea feel free to change it.

Personally I use DB or FILE, because I don't like the DBFILE approach, 
but for sure the DBFILE is the best compromise for performance/stability.

>> > ATM full message retrieval and storage is slow, and requires
>> > that the whole document is loaded into memory.
>>
>> That's a JavaMail issue, and needs to be eliminated.  Regardless of 
>> whether
>> the message is in the DB or a file, we want to stream it if we are
>> processing it at all.
> 
> reads typically require no processing, just pushing the data out a
> socket. i wonder whether a messaging solution would be better: allow
> processors to access a JavaMail view of the message data but create
> this lazily. if there is no processing required, the data is read
> lazily to be written out.

This is exactly what already happen in MimeMessageWrapper: when you read 
messages in POP3 it should not parse the messages but simply stream them.

>> This is orthogonal for having the blob be in a
>> separate table.  The latter allows us improved DB performance (and 
>> sharing
>> of the blob, if that were ever useful).
> 
> AFACT message_body contains the body as a blob (but performance is still 
> poor)
> 
> - robert

How did you measure this performance? In my tests the dbonly solution 
has always been the faster in a typical scenario (I know every case is 
different, but messages greater than 20k are less than 1% on my systems).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message