james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oki DZ <ok...@pindad.com>
Subject Re: cvs commit: jakarta-james/src/conf spool.properties
Date Thu, 02 Aug 2001 02:24:44 GMT
On 1 Aug 2001 serge@apache.org wrote:
>   # SQL Statements
>   # Note that the repository will replace <table> with the table parameter above.
>   listMessagesSQL=SELECT message_name, message_state, last_updated FROM <table>
WHERE repository_name = ? ORDER BY last_updated ASC

I think you should add:
getMessageSizeSQL=SELECT length(message_body) FROM <table> where message_name = ? and
repository_name = ?
to be used in MimeMessageJDBCSource.getSize(). Currently,
MimeMessageSource.getSize() retrieves the data from the input stream and
then adds up the bytes. That's not efficient (especially on databases),
and it's no wonder that executing LIST on the POP server takes a long 

IMHO, MimeMessageWrapper.writeTo(OutputStream) needs to be more optimized.
I tried to retrieve (via POP; ie: telnetting to the server and then
executing RETR <msg num>) a message with a 2 Mbytes of attachment; it took
minutes. Then I tried to retrieve the same message via MySQL's mysql
(using "select ... from Message where ..."); it took seconds. So I think
the problem was not in the database data retrieval; ie: MySQL could serve 
the retrieval much faster than James could read. If the I/O streams were
buffered (using BufferredIn/OutputStream), would that make the retrieval a
bit faster?

BTW, I just downloaded the source from the cvs. I think it's nice to have
an option of having a message-body repository in local file system. But I
guess we should stop adding ad hoc solutions to JDBCMailRepository; it
already has many if's (One for looking up the db whether a particular
message already there, if so, just update everything except the message
body. One more -- the newest entry -- for storing the body in a local file
repository.) IMO, it begins to look like French (the language; I don't
know French, but it's surely complicated, isn't it?).

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

View raw message