0004029: ClientDisconnectException due to 'client timeout'

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

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

Status

closed

Product Version

3.1.9

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)

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[^]

30 total queries executed.
26 unique queries executed.