> My understanding was JDK 1.3 was fine. I did not know this though. good
> link - thanks.
Welcome.
Mind you, that code doesn't accomplish what you seem to think it does.
AFAIK, there is only once scheduler, anyway, coming from the
componentManager.lookup() call, so all you've done is change an instance
reference to a shared object to a static reference to a shared object. A
lot of work for no real gain. So long as the code uses the default
scheduler, the problem remains. I didn't have time to look at your other
scheduler implementation, and you seem to be saying you've got other ideas
to test.
> Butm this was a short term fix. I wanted to limit changes to one file
I don't have a good test for the POP3 side. I have a good test for the SMTP
side (actually, we have two of them now :-)), hence the request for that
service to be the guinea pig. :-)
> It is worthwhile to test and use the best approach.
I agree. One question is how to measure "best". I'd say stability,
performance, and cleanliness are key issues, in just about that order.
I had portal hammering away on Peter's server (with his changes) all night.
It didn't die, but there was a definite performance degradation over time
that needs to be understood and fixed. Unclear if it is in the changes or
if we're just exposing another issue within James. I don't believe that the
problem is in postal because if I stop it and restart the performance picks
up where it left off.
When Andrei did his tests, he commented out the sendMail line in
SMTPHandler, so that he could isolate the Handler's issues from the rest of
James. That is probably a good idea.
- I'll post cleaner code for POP3 and SMTP handler.
- Patch my server.
- Post simpler service/configuration related code.
I look forward to seeing it.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
