Noel J. Bergman wrote:
>>- 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.
>
Just a quick comment on the Avalon logger. First point is that you need to
address the particular logging implementation. The default in James is the
LogKit implementation. Something you should be aware of concerns the usage
of logging catagories in LogKit - i.e. if you declare a logging category
named "james", then a sub-category named "smtp" then both the "james" and
"smtp" catagories exist for the lifetype of the application. If a componet
does something like the creation of a logging channel using an instance
name,
then you can get into a memory problem:
E.g. a log entry like the following is BAD if the number of
subcategories is significant because catagories are not
released.
james.smtp.0125369 hello world
Taking a quick look through the James sources, there are only a couple of
occurances of logging sub-category creation (James and FetchScheduled). In
both cases the number of assigned sub-categories is either static or linked
to a static configuration set - in other words - I don't think you will
be seeing any problems that could be attributed to LogKit.
Cheers, Steve.
>
>>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]>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
