[svn] 869: Bug: BLZ-92 - catch IOException and log at the info level to keep from polluting the logs

Question

Revision: 869
Author: [email protected]
Date: 2008-03-19 15:21:25 -0700 (Wed, 19 Mar 2008)
Log Message:
Bug: BLZ-92 - catch IOException and log at the info level to keep from polluting the logs
QA: Yes
Doc: No
Details:
Tomcat 5+ throws a ClientAbortException when it receives a TCP RST while writing a response to a client that has exited. This custom exception extends IOException, and we were only doing lighter INFO-level logging for SocketExceptions so the ClientAbortException was getting past this leading to ERROR level logging. This little tweak will mean less pollution of the server logs during QE load tests.
Ticket Links:
http://bugs.adobe.com/jira/browse/BLZ-92
Modified Paths:
blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/endpoints/BaseHTTPEndpoint.ja va

Answer 1

Hi AbhijitRoy2005,
Other then climbing in the phone and calling the vendor, you could try:
1. To use a BufferedInputStream to wrap the SocketInputStream before you wrap that in the DataInputStream. So basically:
DataInputStream dis = new DataInputStream(new BufferedInputStream(socket.getInputStream());On one of my implementations this made a difference of a factor of 200+! So instead of processing 500 messages per second, I could process 10000 messages per second!
2. Or to take it to the next level and take a look at using NIO. That is New IO, available since Merlin (Java 1.4). But that would take you way more time then the first attempt.
The thing addressed by the possible solutions above is the blocking nature of the Stream based socket handling. Using a buffered input stream reads ahead. The NIO thing is all about non-blocking IO, which uses Channels and Buffers instead of Sockets and Streams (note that these are not equivalent!).
Of course, if you didn't change something in your own code, it might just very well be that the vendor just screwed up his ;)
Regards,
Frens