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/08/06 06:50:31 UTC
Proposal merged to main branch
The noparse-mimemessage branch (or whatever I called it) has been merged
into the main branch. This has the greatly improved approach to not
parsing/loading mime message, which reduces memory and CPU usage, and also
the JDBC repositories. I also fixed the locking problem Ozi pointed out.
I want to test Ozi's optimization idea for the accept method, but will work
on it later in the week.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Proposal merged to main branch
Posted by Serge Knystautas <se...@lokitech.com>.
Sorry, Oki. I'm known for lots of typos.
I'll have to look into this renaming thing more. If it is sending and
receiving the whole message rather than just updating the message name in
place, that's certainly an area to optimize.
As for the accept, I was going to test to see what happens if accept()
returns bad keys. If things continue fine (an exception is generated and
then tries again), then I think it'll be ok to add an aggressive cache. In
any case, I was just going to have accept store all possible keys in memory
queue, and as accept methods are called, it could return the keys in the
queue one by one. I may have to override a few other methods (namely
lock/unlock) so that if another thread is calling something besides accept
on this repository, the cache will stay with only valid entries. Like you
said, the object is just to reduce the number of calls to the database which
with a lot of threads can be quite significant.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Oki DZ" <ok...@pindad.com>
To: <ja...@jakarta.apache.org>
Sent: Tuesday, August 07, 2001 4:03 AM
Subject: Re: Proposal merged to main branch
> On Mon, 6 Aug 2001, Serge Knystautas wrote:
>
> > The noparse-mimemessage branch (or whatever I called it) has been merged
> > into the main branch. This has the greatly improved approach to not
> > parsing/loading mime message, which reduces memory and CPU usage, and
also
> > the JDBC repositories. I also fixed the locking problem Ozi pointed
out.
>
> If the one you meant was me, then it's "Oki".
>
> > I want to test Ozi's optimization idea for the accept method, but will
work
> > on it later in the week.
>
> That would be cool. But I guess if the messages in outgoing spool are
> always changing names, then you'd have problem. Because, the temporary
> message list will just out of sync with the actual messages in the
> repository (the content would just a list of deleted messages; the ones
> who happen to be retried to be sent).
>
> But please think about optimizing the writeTo() method (the one which
> transfers the message body between James and the db server) also. Maybe a
> buffered input/output streams would do the trick.
>
> BTW, I don't like how James spins out of control when a message retrieved
> from the repository couldn't be found. So I added the following in the
> mail repository's retrieve():
>
> public MailImpl retrieve(String key) {
> MailImpl mc = null;
> try {
> //some setup which sets up a "null" MailImpl
> //a quick hack, using a deprecated method
> Set trecipients = new HashSet();
> trecipients.add(new MailAddress("blackhole@localhost"));
> mc = new MailImpl("errormail" + Math.abs(new
> Random(System.currentTimeMillis()).nextInt()),
> new MailAddress("postmaster@localhost"),
> trecipients,
> new StringBufferInputStream("errmsg"));
> mc.setState(Mail.ERROR);
> // the rest of code as usual
> // ..
>
> Then I added an entry in the config.xml so that mail sent to the address
> will be handled by the Null mailet.
>
> BTW, the Null mailet basically set the message state to Mail.GHOST;
> problem is, James will print out lots of exceptions on the stdout if the
> retrieve() method, some way somehow, couldn't find the message in the
> repository. It seems that James.class doesn't like null messages (there's
> no "if (message = null)". I think the above snippet is the proper way to
> handle the situation.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Proposal merged to main branch
Posted by Oki DZ <ok...@pindad.com>.
On Mon, 6 Aug 2001, Serge Knystautas wrote:
> The noparse-mimemessage branch (or whatever I called it) has been merged
> into the main branch. This has the greatly improved approach to not
> parsing/loading mime message, which reduces memory and CPU usage, and also
> the JDBC repositories. I also fixed the locking problem Ozi pointed out.
If the one you meant was me, then it's "Oki".
> I want to test Ozi's optimization idea for the accept method, but will work
> on it later in the week.
That would be cool. But I guess if the messages in outgoing spool are
always changing names, then you'd have problem. Because, the temporary
message list will just out of sync with the actual messages in the
repository (the content would just a list of deleted messages; the ones
who happen to be retried to be sent).
But please think about optimizing the writeTo() method (the one which
transfers the message body between James and the db server) also. Maybe a
buffered input/output streams would do the trick.
BTW, I don't like how James spins out of control when a message retrieved
from the repository couldn't be found. So I added the following in the
mail repository's retrieve():
public MailImpl retrieve(String key) {
MailImpl mc = null;
try {
//some setup which sets up a "null" MailImpl
//a quick hack, using a deprecated method
Set trecipients = new HashSet();
trecipients.add(new MailAddress("blackhole@localhost"));
mc = new MailImpl("errormail" + Math.abs(new
Random(System.currentTimeMillis()).nextInt()),
new MailAddress("postmaster@localhost"),
trecipients,
new StringBufferInputStream("errmsg"));
mc.setState(Mail.ERROR);
// the rest of code as usual
// ..
Then I added an entry in the config.xml so that mail sent to the address
will be handled by the Null mailet.
BTW, the Null mailet basically set the message state to Mail.GHOST;
problem is, James will print out lots of exceptions on the stdout if the
retrieve() method, some way somehow, couldn't find the message in the
repository. It seems that James.class doesn't like null messages (there's
no "if (message = null)". I think the above snippet is the proper way to
handle the situation.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org