Noel J. Bergman wrote:

After executing the test the SMTP thread is still busily running
consuming as much CPU as it can get.

The following fragment of the SMTP log is typical:

[DEBUG  ] (james.smtp): Command received:

This is bad already.  Where is the command?  We just changed the read code,
but the original code was "return inReader.readLine().trim();" and I don't
think the replacement is broken.

I just did a little debugging - the command is a zero length string.

So I added a little something to the SMTPHandler.pasrseCommand() to check if the command length is 0 and if so, to return false. That has a rather significant impact in that everything appears to be working properly.

if( (rawCommand == null) || ( rawCommand.length() == 0 ) ){
return false;
}




[DEBUG ] (james.smtp): Calling reset() default Worker #1017
[DEBUG ] (james.smtp): Calling reset() default Worker #1423
[DEBUG ] (james.smtp): Calling reset() default Worker #1652
[DEBUG ] (james.smtp): Calling reset() default Worker #214

This is also not good. Those numbers are related to threading. Something
feels truely fouled.

And this has dissapeared.

Cheers, Steve.

p.s. Test execution for 1000 messages took 86 seconds (file storage, 350 MHtz Intel).

--- Noel


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to