----- Original Message -----
From: "Lyallex" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Monday, June 30, 2008 10:11 AM
Subject: How to close an out Stream if a client aborts
Good Morning
Java 1.5.0_15
Tomcat 5.5.26
I have a servlet that is used to serve up images from a database
If the client aborts the connection I get the usual 'broken pipe' type
exceptions
The thing is that from my debug output it appears that the
OutputStream to the client
(instanceof ServletOutputStream) is neither flushed nor closed in this
situation.
I try to close all resources in a finally block but the debug after
outStream.close never appears
I guess I can understand why the stream is not flushed (there is no
connection to flush it to)
but I'm not sure why I can't close the stream, the javadoc doesn't
really help ...
The problem I have is that under heavy load the server crashes silently
(no errors to the logs) and I'm trying to track down why this might be.
If I get loads of unclosed OutputStreams containing uncommitted data
this might be the problem. (yes/no?)
Here's the basic code (logging and debug removed)
public void doService(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
ServletOutputStream outStream = null;
InputStream inStream = null;
try {
outStream = response.getOutputStream();
response.reset();
response.setHeader("Expires", "-1");
response.setHeader("Cache-Control", "no-cache");
String imageId = request.getParameter(WebConstants.IMAGE_ID);
ImageServer images = ImageServer.getServer();
inStream = images.getImageData(imageId);
byte[] bytes = new byte[1000];
int bytesRead = inStream.read(bytes);
while (bytesRead != -1) {
outStream.write(bytes,0,bytesRead);
bytesRead = inStream.read(bytes);
}
//appears to 'hang' here if client breaks connection
outStream.flush();
}
catch (Throwable t) {
//aborted connection type exceptions to log
t.printStackTrace();
}
finally{
//outStream.flush();
//no debug output after here if flush is uncommented here
inStream.close();
//debug here appears OK
outStream.close();
//debug here never appears if client breaks connection
}
}
The whole thing works perfectly in the situiation where the client
doesn't abort the connection.
I'm not asking anyone to solve my problem, I'm just trying to figure
out if I'm looking in the right place, possibly.
Could this potentially be where the problem lies ?
Lyallex, I actually never stopped to give in much thought, but looking back
at code I've done, I see I have...
//if (out != null) { out.close(); }
Commented out as well...
I know the output stream sits ontop of the buffer... and that they are
automatically recycled when a connection is reused.
So they will clean up, even if that is not immediately.
Under normal op thats probably ok coz the buffer is empty... otherwise it
carries the baggage until connection is reused.
I think it may even cause problems even without a client termination.
I got it commented out and I doubt whether it was a client termination test
that made me do it... cant remember the reason...
I think its a subclass of the actual buffer... which may be sending the last
packet, or chunk... and when we whack it closed... it just sits there,
nothing to send to a waiting browser. So its hanging becaue the browser is
waiting for TC, which has nothing to say.
Its not new... that I noticed on 5.5. A finally... runs either way... so it
may not be a browser cancel, that may come after the user is wondering why
it never came, and they clicked refresh.
Good question... it does seem to fly in the face of convention.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
