Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0004029 [Resin] minor random 05-05-10 17:18 05-19-10 15:05
Reporter iRideSnow View Status public  
Assigned To ferg
Priority normal Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 4.0.7 Product Version 3.1.9
  Product Build
Summary 0004029: ClientDisconnectException due to 'client timeout'
Description 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)
Steps To Reproduce
Additional Information
Attached Files

- Relationships

- 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.
 

- Issue History
Date Modified Username Field Change
05-05-10 17:18 iRideSnow New Issue
05-05-10 17:19 iRideSnow Issue Monitored: iRideSnow
05-19-10 15:05 ferg Note Added: 0004596
05-19-10 15:05 ferg Assigned To  => ferg
05-19-10 15:05 ferg Status new => closed
05-19-10 15:05 ferg Resolution open => fixed
05-19-10 15:05 ferg Fixed in Version  => 4.0.7


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
30 total queries executed.
26 unique queries executed.
Powered by Mantis Bugtracker