You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by se...@apache.org on 2001/08/01 05:54:59 UTC
cvs commit: jakarta-james/src/conf spool.properties
serge 01/07/31 20:54:59
Added: src/conf spool.properties
Log:
Sample JDBC Repository configuration file.
Revision Changes Path
1.1 jakarta-james/src/conf/spool.properties
Index: spool.properties
===================================================================
#This is a sample configuration file for the JDBCMailRepository
#These are the two parameter you will probably want to change most often
table=Message
#What is stored in the repository_name. This let's you use the same table to store multiple repositories
repository=spool
#this is connection information
driver=com.inet.tds.TdsDriver
URL=jdbc:inetdae7:127.0.0.1?database=James
username=sa_james
password=blahblah
#This is an optional directory where this repository should store message bodies. This can significantly improve your performance, but at the cost of some robustness.
filestore=file://var/dbspool/
# SQL Statements
# Note that the repository will replace <table> with the table parameter above.
checkMessageExistsSQL=SELECT count(*) FROM <table> WHERE message_name = ? AND repository_name = ?
updateMessageSQL=UPDATE <table> SET message_state = ?, error_message = ?, sender = ?, recipients = ?, remote_host = ?, remote_addr = ?, last_updated = ? WHERE message_name = ? AND repository_name = ?
updateMessageBodySQL=UPDATE <table> SET message_body = ? WHERE message_name = ? AND repository_name = ?
insertMessageSQL=INSERT INTO <table> (message_name, repository_name, message_state, error_message, sender, recipients, remote_host, remote_addr, last_updated, message_body) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
retrieveMessageSQL=SELECT message_state, error_message, sender, recipients, remote_host, remote_addr, last_updated FROM <table> WHERE message_name = ? AND repository_name = ?
retrieveMessageBodySQL=SELECT message_body FROM <table> WHERE message_name = ? AND repository_name = ?
removeMessageSQL=DELETE FROM <table> WHERE message_name = ? AND repository_name = ?
listMessagesSQL=SELECT message_name, message_state, last_updated FROM <table> WHERE repository_name = ? ORDER BY last_updated ASC
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Contributions (Was Re: cvs commit: jakarta-james/src/conf spool.properties)
Posted by Peter Donald <do...@apache.org>.
On Fri, 3 Aug 2001 18:32, Charles Benett wrote:
> If the copyright is not assigned to the ASF, I'm not sure we can include
> it in the cvs repository. (We'd need to check, if that is what you are
> proposing.)
Nope you can not unless it is never worked upon/changed by Apache peoples
(like SAX or JAXP classes) however even then they have to be under a license
that is usable by Apache.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Contributions (Was Re: cvs commit: jakarta-james/src/conf spool.properties)
Posted by Harmeet <ha...@kodemuse.com>.
> BTW, I'm not quite familiar with CVS; what is the exact command to have
> the diff files? I have tried okidz@bdg:~/jakarta-james$cfs diff -u, but I
> don't think that it's the right command. I have some new classes too. I
> don't know how to take them into account.
If you use emacs cvs-mode-diff-cvs would help.
Don't know the command line syntax, but http://www.cvshome.org/ should help.
Harmeet
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Contributions (Was Re: cvs commit: jakarta-james/src/conf spool.properties)
Posted by Oki DZ <ok...@pindad.com>.
On Fri, 3 Aug 2001, Charles Benett wrote:
> If the code is contributed to james, ie the copyright is assigned to the
Yes, that's what I've been thinking.
> Apache Software Foundation, then I think it should go in the main source
> with an org.apache.james.* package.
I see.
>There is then a separate question
> of comiling sars with the particular set of classes someone wants. But
> the default distribution would probably have the whole lot.
>
> If the copyright is not assigned to the ASF, I'm not sure we can include
> it in the cvs repository. (We'd need to check, if that is what you are
> proposing.) If we can't include it in the repository, maybe we could
> have a webpage that lists james-compatible code and links to sites where
> they can be downloaded.
This would be too much trouble, I think
> Clearly, a straight contribution would be preferable.
Quite understandable.
> In general, I have no problem with james having alternative
> implementations, so long as there are good reasons for each one.
One of my reasons was to provide proof of concept code. I don't think that
quickly implementing new ideas on the main branch is a good thing; eg:
temporary storage on local filesystems for James which uses db
repositories. The feature might be good, but is it the right solution?
Couldn't it be regarded as half cooked? Think about not just a temporary
file storage but also a cache that automatically retrieves all the rest of
the data once a user tries to fetch the mail via POP; meaning: when the
pop server sending out a message, it also retrieves the rest in the
background. If there were 10 messages left, then there would be 10
concurrent connections to the database. But then again, that scenario
would be good if the db server and James were in separate machines. If in
a single machine, that wouldn't be appropriate.
On the other hand, I have some unproven ideas that I'd like to be
implemented; ie: the use of a global cache that temporarily stored message
names in the spool repository, so that each invocation of accept() method
doesn't have to execute a query to the db server. Asking in this list
so that the feature can be implemented is the right thing to do. But if I
have time to implement it, that would make the implementation faster,
right? Problem is, the differences in the code is not only in
JDBCMail/SpoolRepository, but also in some other classes. Quickly
integrating it with James, even with the classes in the proposals
directory, is not quite acceptable. But of course, I'd like others to test
my code.
> If you are happy to assign contribute the code to apache and people on
> the list who know more about dbs than me agree, we could include your
> stuff as well as Serge's.
I think I'm going to test my code and let it running for a while. Then I'm
going to rename the package names, create some diff files, and send it to
you.
BTW, I'm not quite familiar with CVS; what is the exact command to have
the diff files? I have tried okidz@bdg:~/jakarta-james$cfs diff -u, but I
don't think that it's the right command. I have some new classes too. I
don't know how to take them into account.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Contributions (Was Re: cvs commit: jakarta-james/src/conf
spool.properties)
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Oki DZ wrote:
>
> On Thu, 2 Aug 2001, Charles Benett wrote:
>
> > I haven't tried it, but it should be as simple as ./build.sh
> > -Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true
>
> I did that when I tried to use Serge's noparse-mimemessage. But that's
> the command for getting the appropriate files in the build directory (ie:
> not for submission).
>
> As I understand it, the proposal directories contain the source which
> would eventually become included in the distribution.
Correct
> I was thinking about
> a "contrib" directory, where the source files would be in there and be
> used according to the user's needs. For example, mailets. I believe that
> there would be more mailets being written (by non-committers), and I don't
> think that putting them all in the .sar file would be useful. So, the
> contrib directory would be a nice place to put them; and then have the
> mailets included by executing the build.sh command with the appropriate
> options.
>
> That's just about semantics (different rendering of the word "proposal"),
> though; if what is meant with "proposal" also represent what I meant with
> the "contrib" above, then there's no reason in creating a new directory.
> We can use what's already available. But... I don't think that creating a
> "contrib" directory would be costly. Besides, it would make ones more
> relaxed in submitting codes; they don't have to be committers.
>
> Well, I believe that I still have something missing; if you submit source
> files to the CVS, should the package names have "org.apache" in them? I
> guess not. If it is, then it's too restrictive. If the restriction should
> be in place, then the "contrib" might be an acceptable solution; so that
> ones could submit codes with any package names they like. And also, the
> submitted codes don't have to be working out of the box; eg: a submitter
> might upload a mail repository that expects totally different database
> schema for the repository table.
>
> The mail repository may not be needed by most of the James users, but
> somebody might badly need it given the same environment where James is
> expected to be run. Think about a mail repository that implements direct
> calls to MySQL client libraries via JNI (Java Native Interface) to speed
> things up. I believe such repository doesn't belong to the main branch in
> the CVS; the code wouldn't be that portable, tightly tied to the operating
> system where the repository should be run. But it would be really nice if
> the code is accessible by the James users at large, and it would need a
> nice place where to put it.
If the code is contributed to james, ie the copyright is assigned to the
Apache Software Foundation, then I think it should go in the main source
with an org.apache.james.* package. There is then a separate question
of comiling sars with the particular set of classes someone wants. But
the default distribution would probably have the whole lot.
If the copyright is not assigned to the ASF, I'm not sure we can include
it in the cvs repository. (We'd need to check, if that is what you are
proposing.) If we can't include it in the repository, maybe we could
have a webpage that lists james-compatible code and links to sites where
they can be downloaded.
Clearly, a straight contribution would be preferable.
>
> > BTW, what are you working on?
>
> MySQLMailRepository, MySQLSpoolRepository, and UsersMySQLRepository that
> implement Turbine's db connection pooling. The spool repository implements
> a global cache that temporarily stores the list of the messages that
> resides in the spool; so that when the spool repository's accept() method
> gets invoked (after the first invocation), there would be no additional
> SQL query sent to the db server. This would make the spool works faster I
> believe, even if the db pooling is already there.
In general, I have no problem with james having alternative
implementations, so long as there are good reasons for each one.
If you are happy to assign contribute the code to apache and people on
the list who know more about dbs than me agree, we could include your
stuff as well as Serge's.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Oki DZ <ok...@pindad.com>.
On Fri, 3 Aug 2001, Darrell DeBoer wrote:
> I don't think that db-specific subclasses is the right design for handling
> different databases.
I use the name to stress (to myself) that it would be all right to use
whathever non-standard SQL statements available in MySQL (it turned out
that for the task at hand, there ain't any :-). Besides, I just wanted to
have class names that don't collide with the existing JDBC* classes in
James.
>I reckon that database-specific implementations would be
> better built using a containment relationship with a database-specific
> "plugin" (ie bridge pattern). Even better if we can stick to using meta-data
> (ie config) for all database-specific needs.
I was talking about that in my previous postings; using a superclass of
JDBCMailRepository, which contains nothing but SQL statement definitions.
But I think, yes, it'd be better to use meta-data files.
> The use of inheritance in this
> case is not the best design, in my opinion.
> (I'm assuming that the classes named above follow on from a previous email
> which described the design in more detail)
Well, I didn't use inheritance; it was a complete rewrite.
So I think, I didn't follow one of the good practices in OOP; ie:
reusability. :-) But it's OK, I have learned quite a lot. (That's the
greatest thing about open-source, I believe; you don't just implement
others' works, but you also learning something along the way.)
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Darrell DeBoer <li...@bigdaz.com>.
On Fri, 3 Aug 2001 11:38, Oki DZ wrote:
> On Thu, 2 Aug 2001, Charles Benett wrote:
> > BTW, what are you working on?
>
> MySQLMailRepository, MySQLSpoolRepository, and UsersMySQLRepository that
> implement Turbine's db connection pooling. The spool repository implements
> a global cache that temporarily stores the list of the messages that
> resides in the spool; so that when the spool repository's accept() method
> gets invoked (after the first invocation), there would be no additional
> SQL query sent to the db server. This would make the spool works faster I
> believe, even if the db pooling is already there.
I don't think that db-specific subclasses is the right design for handling
different databases. I reckon that database-specific implementations would be
better built using a containment relationship with a database-specific
"plugin" (ie bridge pattern). Even better if we can stick to using meta-data
(ie config) for all database-specific needs. The use of inheritance in this
case is not the best design, in my opinion.
(I'm assuming that the classes named above follow on from a previous email
which described the design in more detail)
Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Oki DZ <ok...@pindad.com>.
On Thu, 2 Aug 2001, Charles Benett wrote:
> I think Serge was talking about my suggestion that you might want e.g.
> spool, spam and error mesages in a different db (which may or may not
> mean a different db server) from the POP3 inboxes.
I see.
> I'd have thought it was very likely that people might have their Users
> in a different db or db server from their mail.
I think the more features James has, the better. Problem is, how easy is
it in configuring it. If it's pretty easy, then it would be all right.
> I haven't tried it, but it should be as simple as ./build.sh
> -Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true
I did that when I tried to use Serge's noparse-mimemessage. But that's
the command for getting the appropriate files in the build directory (ie:
not for submission).
As I understand it, the proposal directories contain the source which
would eventually become included in the distribution. I was thinking about
a "contrib" directory, where the source files would be in there and be
used according to the user's needs. For example, mailets. I believe that
there would be more mailets being written (by non-committers), and I don't
think that putting them all in the .sar file would be useful. So, the
contrib directory would be a nice place to put them; and then have the
mailets included by executing the build.sh command with the appropriate
options.
That's just about semantics (different rendering of the word "proposal"),
though; if what is meant with "proposal" also represent what I meant with
the "contrib" above, then there's no reason in creating a new directory.
We can use what's already available. But... I don't think that creating a
"contrib" directory would be costly. Besides, it would make ones more
relaxed in submitting codes; they don't have to be committers.
Well, I believe that I still have something missing; if you submit source
files to the CVS, should the package names have "org.apache" in them? I
guess not. If it is, then it's too restrictive. If the restriction should
be in place, then the "contrib" might be an acceptable solution; so that
ones could submit codes with any package names they like. And also, the
submitted codes don't have to be working out of the box; eg: a submitter
might upload a mail repository that expects totally different database
schema for the repository table.
The mail repository may not be needed by most of the James users, but
somebody might badly need it given the same environment where James is
expected to be run. Think about a mail repository that implements direct
calls to MySQL client libraries via JNI (Java Native Interface) to speed
things up. I believe such repository doesn't belong to the main branch in
the CVS; the code wouldn't be that portable, tightly tied to the operating
system where the repository should be run. But it would be really nice if
the code is accessible by the James users at large, and it would need a
nice place where to put it.
> BTW, what are you working on?
MySQLMailRepository, MySQLSpoolRepository, and UsersMySQLRepository that
implement Turbine's db connection pooling. The spool repository implements
a global cache that temporarily stores the list of the messages that
resides in the spool; so that when the spool repository's accept() method
gets invoked (after the first invocation), there would be no additional
SQL query sent to the db server. This would make the spool works faster I
believe, even if the db pooling is already there.
Also some fix up in the MimeMessageJDBCSource (well, I created
MimeMessageMySQLSource class); I reimplemented (by overriding) the
getSize() method using an SQL query to the server.
>If they are not too long, you can email
> the source to the list and someone can commit it for you. Alternatively,
> you can email it to a committer (e.g. me, Serge, etc.) and ask them to.
I see. This is much more simpler. I'm going to have some fix ups on the
mail repository; currently, I have all the prepared statements created
once in the initialize() method, inadvertently forgetting that the
instance of the mail spool is only one but more than one thread of spool
manager may access the spool in a given time.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Oki DZ wrote:
>
> On Wed, 1 Aug 2001, Serge Knystautas wrote:
> > 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. :)
>
> You already have the SQL statements in a properties file (CVS James). And
> you could supply James with the appropriate properties file for each db
> supported by James. IMO, it's not a problem, not a problem at all. All the
> admin needs is to rename one of the supplied properties file to the right
> one. Besides, it makes POP's LIST _tons_ faster. Yes, I have implemented
> it by rewriting JDBCMail/SpoolRepository (and surely, with constantly
> looking at your JDBCMail/SpoolRepository during the rewrite :-)
>
> > 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?
>
> Nice idea; I'll try that sometime. (But again, as always, complaining in
> this list is a lot easier and faster :-)
>
> >Comparing it against the native tool isn't a
> > fair comparison.
>
> It might not be fair, but the time difference was so big, and it made me
> really wonder. And I think getting James speeding up is one of the right
> objectives, right? The native tool could be used as a time reference.
>
> > I agree it's starting to look a bit like [language you don't speak]. The
>
> +1
> (just try things out)
>
> > 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.
>
> -1
> (is this the right dev-speak?)
>
> You mean like the UsersRepository in a database server and MailRepository
> in another one? I see no point in that.
I think Serge was talking about my suggestion that you might want e.g.
spool, spam and error mesages in a different db (which may or may not
mean a different db server) from the POP3 inboxes.
I'd have thought it was very likely that people might have their Users
in a different db or db server from their mail.
>
> >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).
>
> Nice idea; and I like the way build.xml's "proposals" works. BTW, can I
> have mine also? ie: by simply have a new directory (and have some codes
> inside) and then execute the right command for ant? I already have some
> source files, but I put it directly under .jakarta-james/src/java; it's
> the wrong way, I believe. I've been dreaming about uploading something to
> the CVS, and the wrong way would make it difficult.
I haven't tried it, but it should be as simple as ./build.sh
-Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true
BTW, what are you working on? If they are not too long, you can email
the source to the list and someone can commit it for you. Alternatively,
you can email it to a committer (e.g. me, Serge, etc.) and ask them to.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Oki DZ <ok...@pindad.com>.
On Wed, 1 Aug 2001, Serge Knystautas wrote:
> 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. :)
You already have the SQL statements in a properties file (CVS James). And
you could supply James with the appropriate properties file for each db
supported by James. IMO, it's not a problem, not a problem at all. All the
admin needs is to rename one of the supplied properties file to the right
one. Besides, it makes POP's LIST _tons_ faster. Yes, I have implemented
it by rewriting JDBCMail/SpoolRepository (and surely, with constantly
looking at your JDBCMail/SpoolRepository during the rewrite :-)
> 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?
Nice idea; I'll try that sometime. (But again, as always, complaining in
this list is a lot easier and faster :-)
>Comparing it against the native tool isn't a
> fair comparison.
It might not be fair, but the time difference was so big, and it made me
really wonder. And I think getting James speeding up is one of the right
objectives, right? The native tool could be used as a time reference.
> I agree it's starting to look a bit like [language you don't speak]. The
+1
(just try things out)
> 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.
-1
(is this the right dev-speak?)
You mean like the UsersRepository in a database server and MailRepository
in another one? I see no point in that.
>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).
Nice idea; and I like the way build.xml's "proposals" works. BTW, can I
have mine also? ie: by simply have a new directory (and have some codes
inside) and then execute the right command for ant? I already have some
source files, but I put it directly under .jakarta-james/src/java; it's
the wrong way, I believe. I've been dreaming about uploading something to
the CVS, and the wrong way would make it difficult.
> We can always make the code more readable later... as long as it works
> well and has a good design.
Sure, works well, faster, and has a good design.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Serge Knystautas <se...@lokitech.com>.
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
http://www.lokitech.com/
----- Original Message -----
From: "Oki DZ" <ok...@pindad.com>
To: <ja...@jakarta.apache.org>
Cc: <ja...@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
Re: cvs commit: jakarta-james/src/conf spool.properties
Posted by Oki DZ <ok...@pindad.com>.
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?).
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org