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: Proposal merged to main branch
Date Tue, 07 Aug 2001 14:32:48 GMT
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
----- Original Message -----
From: "Oki DZ" <okidz@pindad.com>
To: <james-dev@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
> > the JDBC repositories.  I also fixed the locking problem Ozi pointed
> 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
> > 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

View raw message