Noel J. Bergman wrote:
I just did a little debugging - the command is a zero length string.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.
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;
}
And this has dissapeared.
[DEBUG ] (james.smtp): Calling reset() default Worker #1017This is also not good. Those numbers are related to threading. Something
[DEBUG ] (james.smtp): Calling reset() default Worker #1423
[DEBUG ] (james.smtp): Calling reset() default Worker #1652
[DEBUG ] (james.smtp): Calling reset() default Worker #214
feels truely fouled.
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]>
