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 Serge Knystautas <se...@lokitech.com> on 2001/06/28 05:50:32 UTC
Proposal working
Charles,
Whatever you did to structure my proposal in CVS, thanks! I'm not getting
the out of memory exception and am back to testing.
I wrote implementations on MimeMessageWrapper.writeTo(OutputStream [, String
headers[]}. They now stream the source (inputstream) to the specified
outputstream, rather than parsing and instantiating the MimeMessage. Now
it's instantiating the message only once rather than 4-5 times (between when
it received, sent, and processed the message through different processors).
Next, I plan to have it only instantiate the headers first, only
instantiating the whole message if that's necessary. This will help a lot
as for most messages, you just check headers and don't need the whole
MimeMessage.
Anyway, just wanted to say thanks mainly!
Serge
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Proposal working
Posted by Serge Knystautas <se...@lokitech.com>.
Yeah, I focused just on getting all the optimization working last night
(also got the headers thing working late last night). Will finish debugging
JDBC next.
Hmm. as for the JDBC configuration, I'm not sure how to implement your
idea. I was expecting to have just a single database server. The "db://"
repository would be configured with a username, password, driver, and
hostname (like the Town one is in 1.2rc1 release). Then
db://EML_Spool/spool would represent db://<table_name>/<repository_name>.
So you could either stick it all in the same table with different
repository_names, or different tables. Right now the conf is hardcoded
while I test things.
I'm not really sure how to support multiple servers though. The JDBC URL
can be quite arbitrary, and I don't see how you could specify the driver,
username, password, table name, and repository_name (as well as the JDBC
URL) in a single destinationURL. I'm fine with extra flexibility with a
longer conf file, but just am not sure how to do it.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Charles Benett" <ch...@benett1.demon.co.uk>
To: <ja...@jakarta.apache.org>
Sent: Thursday, June 28, 2001 5:45 AM
Subject: Re: Proposal working
> No problem!
>
> But I can't get the jdbc mail repository working :-(
>
> Where do I specify driverclass, db url, user & pass?
>
> How do your URLs work? Spool repository has
> destinationURL="db://EML_SPOOL/spool"
> where I was expecting something like the UsersJDBCRepository:
> <dburl>jdbc:mysql://127.0.0.1/mail</dburl>
>
> What is the role of 'repository_name' as a db table column?
> Does that mean all repositories are in the same table?
> Can you have error messages and spam messges go to different tables in
> the same db and inbox messages go to a db on a different host?
> I'd vote for maximum flexibility for the admin, even if it means bigger
> conf.xml elements per repository.
>
> Good luck,
>
> Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Proposal working
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
No problem!
But I can't get the jdbc mail repository working :-(
Where do I specify driverclass, db url, user & pass?
How do your URLs work? Spool repository has
destinationURL="db://EML_SPOOL/spool"
where I was expecting something like the UsersJDBCRepository:
<dburl>jdbc:mysql://127.0.0.1/mail</dburl>
What is the role of 'repository_name' as a db table column?
Does that mean all repositories are in the same table?
Can you have error messages and spam messges go to different tables in
the same db and inbox messages go to a db on a different host?
I'd vote for maximum flexibility for the admin, even if it means bigger
conf.xml elements per repository.
Good luck,
Charles
Serge Knystautas wrote:
>
> Charles,
>
> Whatever you did to structure my proposal in CVS, thanks! I'm not getting
> the out of memory exception and am back to testing.
>
> I wrote implementations on MimeMessageWrapper.writeTo(OutputStream [, String
> headers[]}. They now stream the source (inputstream) to the specified
> outputstream, rather than parsing and instantiating the MimeMessage. Now
> it's instantiating the message only once rather than 4-5 times (between when
> it received, sent, and processed the message through different processors).
>
> Next, I plan to have it only instantiate the headers first, only
> instantiating the whole message if that's necessary. This will help a lot
> as for most messages, you just check headers and don't need the whole
> MimeMessage.
>
> Anyway, just wanted to say thanks mainly!
>
> Serge
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org