james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Knystautas" <ser...@lokitech.com>
Subject Re: cvs commit: jakarta-james/src/conf spool.properties
Date Thu, 02 Aug 2001 02:48:30 GMT
I like the idea about the size SQL query.  However, there isn't a standard
SQL function to do this.  MS SQL uses "datalength(message_body)", while
mysql (I'm assuming from your example) uses "length(message_body)".  This
makes it more complicated to use out of the box because the admin would have
to configure the SQL for their database vendor.  I could always make the SQL
statement optional and add more if's to the code. :)

As for performance, I don't think James has much to do with the slowness (I
think it's the JDBC driver).  Can you test using the mysql JDBC connection
to retrieve the large message?  Comparing it against the native tool isn't a
fair comparison.

I agree it's starting to look a bit like [language you don't speak].  The
good thing though is that I think it's about as complicated as it can be.
The only other feature I've heard requested is to store the message in
another database.  While this class is getting a bit tough to read, I think
it'd be easier to maintain this one class than to start branching and making
near duplicate versions of the code (for the DB and DB/file versions).  We
can always make the code more readable later... as long as it works well and
has a good design.

Serge Knystautas
Loki Technologies
----- Original Message -----
From: "Oki DZ" <okidz@pindad.com>
To: <james-dev@jakarta.apache.org>
Cc: <jakarta-james-cvs@apache.org>
Sent: Wednesday, August 01, 2001 10:24 PM
Subject: Re: cvs commit: jakarta-james/src/conf spool.properties

> 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
> time.
> 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