i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the InputStream.read(). as everybody should know, InputStrean.read() returns -1 if the end of the inputstream is reached.
this case is checked, but instead of doing something useful, the case is not really handled.
It's handled, the connection is closed.
yes, but it's important to be abled to differ between a "normal" connection shutdown, and a erroneous connection shutdown.
i don't see such a difference in the code right now.
i suggest throwing an EOSException (EOS=EndOfStream) which is derived from IOException.
as this.read() is supposed to read exactly len bytes, it should only throw the EOSException, if the first call of InputStream.read() in the loop returns -1.
I'd prefer avoid generation too many exceptions in real-time environnement. After all if read return something < 0, the loop
is exited and the connection closed in the finally block.
return special values is quite C-stylish.
using exception is the OOP way. i don't know, if throwing an exception is that slow, although a new object has to be created every time :-( which might make things slow.
on the other hand, exceptions don't occur very often (that's why they're called exceptions) and they shouldn't make it that slow.
FYI, Apache close ajp13 connections each time it recycle/kill a child and under heavy load on webserver, it happen very often.
that makes it even worse.
If the webserver has closed a connection, tomcat detect it has close the connection silently....
... except writing those messages to the log.
Usually I'd rather like see patches instead of coding style critics. You're welcome to provide us your solution.
I'm currently trying to compile tomcat (checked out from cvs) and i will supply you with a patch as soon as i've solved the problem.
cu Sven
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
