> -> connections are accepted
> -> resources are consumed
> -> limits are approached
> -> connections are refused
> -> resources are freed
> -> connections are accepted
I believe that the new code facilitates that, but the code still needs work.
There are bugs in it that Peter is working on, but first he had to delete 12
hours worth of messages (100s of 1000s). Meanwhile, I have been working
with Harmeet, too, and crashing his server in about 2 mins each test. Both
of them have removed the sendMail call from SMTPHandler so that we can test
JUST the handler (and so that Peter doesn't have to delete all of those
messages -- which is a completely separate overall issue).
Harmeet's still crashes just in the SMTPHandler with an out of memory error.
Right now I am hitting Peter's server at about the same rate as I was
hitting Harmeet's, except that there doesn't appear to be any leaking
because instead of creating scheduler entries or TimerTask objects (the
Avalon default scheduler and java.util.Timer both maintain priority queues
and simply mark cancelled objects as removable), there is a constant and
small watchdog. More on this in another message.
> In addition it concerns me that we can't run James under the -server JVM
otpion on linux
I do.
> what we need to do is ensure that the server will continue
> to function, even if this means rejecting connections.
Agreed.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
