> > 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.
I just verified that manually going to the old code and using ^M^J results
in a 500 error for the ^J, since it is treated as an eol after the ^M has
already been so treated. The current code does that same. I think that's
just a buffer timing issue. My point is that the existing stable code would
also have provided an empty line under the same circumstances. As a matter
of fact, I believe that the 500 should be sent for an empty line, as it has
been in previous releases.
Check me on something, please. Look at readCommandLine and tell if me if
the in.mark(1) call should be moved. I think that the correct code is:
...
b = (byte) in.read();
if (b == 13) {
//We're done, but we want to see if \n is next
in.mark(1); <-- here, not before the prior read
b = (byte) in.read();
if (b != 10) {
in.reset();
}
break;
} ...
I've made no other changes on my end, and will leave a stress test running.
Right now it is running about 1200 messages per minute.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
