Mantis - Resin
Viewing Issue Advanced Details
4029 minor random 05-05-10 17:18 05-19-10 15:05
iRideSnow  
ferg  
normal  
closed 3.1.9  
fixed  
none    
none 4.0.7  
0004029: ClientDisconnectException due to 'client timeout'
This is a near duplicate of closed bug 3472 <http://bugs.caucho.com/view.php?id=3472>. [^]

In 3472, Scott says it's important to throw the exception because it's a read, as opposed to a write, and for "the application [to have] a chance to detect a partial post."

My question is, given that there is nothing in the stack trace that isn't Caucho's own code, at what point can we catch this exception and do what we need to do to resolve it? Or quietly ignore it if that's what we want to do.

The problem is that we see this fairly frequently on some of our servers and don't know the root cause so we're not even sure where to start looking to see if we can try to prevent it from happening, or at least handle it gracefully instead of seeing these exceptions throughout our log files.

Here's the exact stack trace:

[16:44:21.025] com.caucho.vfs.ClientDisconnectException: client timeout
[16:44:21.025] at com.caucho.vfs.JniStream.exception(JniStream.java:175)
[16:44:21.025] at com.caucho.vfs.JniStream.read(JniStream.java:73)
[16:44:21.025] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1015)
[16:44:21.025] at com.caucho.vfs.ReadStream.read(ReadStream.java:425)
[16:44:21.025] at com.caucho.server.http.ContentLengthStream.read(ContentLengthStream.java:74)
[16:44:21.025] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1015)
[16:44:21.025] at com.caucho.vfs.ReadStream.skip(ReadStream.java:384)
[16:44:21.025] at com.caucho.server.connection.AbstractHttpRequest.skip(AbstractHttpRequest.java:1907)
[16:44:21.025] at com.caucho.server.http.HttpRequest.skip(HttpRequest.java:1212)
[16:44:21.025] at com.caucho.server.connection.AbstractHttpResponse.finish(AbstractHttpResponse.java:2162)
[16:44:21.025] at com.caucho.server.connection.AbstractHttpResponse.close(AbstractHttpResponse.java:279)
[16:44:21.025] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:204)
[16:44:21.025] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
[16:44:21.025] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
[16:44:21.025] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
[16:44:21.025] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
[16:44:21.025] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
[16:44:21.025] at java.lang.Thread.run(Thread.java:619)

Notes
(0004596)
ferg   
05-19-10 15:05   
This is basically just a logging issue. The HTTP request didn't send the full length before quitting. Since it's after the request, I'm changing the logging to only log that stack trace at the finer level.