> - Test with a month or few months old version of James after
> commenting out scheduler from SMTP Handler.
I don't believe that the scheduler is the issue. Peter's code uses the
Watchdog, and that code doesn't create any new object instances during the
main loop of the handler:
while (parseCommand(readCommandLine())) {
theWatchdog.resetWatchdog();
}
public void resetWatchdog() {
lastReset = System.currentTimeMillis();
}
Since I can reproduce this problem on a single connection, we are never
leaving that loop, and therefore it implies that the problem is most likely
somewhere within the handling body.
> We should find out from Avalon lists or ask Avalon folks
if they know of any memory leak issues.
Since we have commented out the sendMail operation, the same logic applied
above should also tentatively eliminate the Avalon lifecycle components from
consideration, as well as the Avalon thread pool. Only the Avalon logger is
used.
> Another possible idea: Create a James version without Avalon
> and see if that is better. Mixed feelings about this but may
> be good to look into.
ROFL. Right, I'll get right on that, I will.
What would be useful is if the handlers were more easily unit tested. I'll
run some tests with -verbosegc turned on (q.v.,
http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html).
Perhaps other folks might like to help look through the main loop processing
for a "HELO, MAIL FROM, RCPT TO, DATA" cycle, and see if they can spot any
issues.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
