You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by czeno2002 <cz...@yahoo.com> on 2009/05/14 14:35:14 UTC
Tomcat ReadTimout on Http post
Hi,
I'm experiencing a really ugly readtimout problem in the production system
started a couple of days ago. The main problem is that there is no way to
reproduce it at all and it happens only on the production boxes aprox 5
times at every hour.
We have a Cisco load balancer up front (no session stickiness) and 3 tomcat
instances (version 5.5) in the back and the site is over the SSL ( between
client and LoadBalance)
My first thought was that the problems happens when the client connection is
really slow, but unfortunately not :(.
I've also checked the LoadBalancer configuration for strange rules or packet
rejection policies but nothing ... anyway the error occurs only on HTTP POST
and it seams that there is no request body is delivered, it is just the
header.
Does somebody has some ideas ? Or at least what can I do in order to
reproduce it ?
I’ve check the request header info and the request are coming from different
IPs and from browsers agents ( IE6, IE7 )
The stack trace is the following:
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at
java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:748)
at
org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:778)
at
org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:116)
at
org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:713)
at org.apache.coyote.Request.doRead(Request.java:419)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:265)
at
org.apache.catalina.connector.InputBuffer.realReadChars(InputBuffer.java:311)
at
org.apache.tomcat.util.buf.CharChunk.substract(CharChunk.java:412)
at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:348)
at
org.apache.catalina.connector.CoyoteReader.read(CoyoteReader.java:105)
at
org.apache.catalina.connector.CoyoteReader.readLine(CoyoteReader.java:154)
--
View this message in context: http://www.nabble.com/Tomcat-ReadTimout-on-Http-post-tp23539641p23539641.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat ReadTimout on Http post
Posted by czeno2002 <cz...@yahoo.com>.
Caldarale, Charles R wrote:
>
>> From: czeno2002 [mailto:czeno2002@yahoo.com]
>> Subject: Tomcat ReadTimout on Http post
>>
>> I'm experiencing a really ugly readtimout problem in the production
>> system started a couple of days ago. The main problem is that there
>> is no way to reproduce it at all and it happens only on the production
>> boxes aprox 5 times at every hour.
>
> That sounds like it's reproducible to me - you just have to wait a bit.
>
>> Does somebody has some ideas ?
>
> Does the Cisco box have any means of logging an hour's worth of traffic?
> If not, can you enable the AccessLogValve in each Tomcat?
>
> What generates the POSTs? If it's JavaScript on the page, is it possible
> it's broken under some odd conditions? Is it possible that some users are
> double-clicking some button on the browser, causing a request to be fired
> off, then quickly abandoned for another?
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
>
>
Hi Chuck,
Thanks for feedback,
Enable loggin on Cisco LB is not really possible in production. Regarding
AccessLogValve we already have activated this logging too, but do not helps
as too much in order to find out the cause of the problem.
The POST is genereated by jQuery on front end and side and contains some
simple and short ( aprox. 60 characheter length) json messages. The double
click scenario is excluded because we disable the buttons after the user
clicked on it.
What we want to try now is to put a sniffer between the cisco and one of the
tomcat and to see if we find something. We expect to find some inconsistent
data or something ...., but if not, I do not know what we can do next ....
--
View this message in context: http://www.nabble.com/Tomcat-ReadTimout-on-Http-post-tp23539641p23593440.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat ReadTimout on Http post
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: czeno2002 [mailto:czeno2002@yahoo.com]
> Subject: Tomcat ReadTimout on Http post
>
> I'm experiencing a really ugly readtimout problem in the production
> system started a couple of days ago. The main problem is that there
> is no way to reproduce it at all and it happens only on the production
> boxes aprox 5 times at every hour.
That sounds like it's reproducible to me - you just have to wait a bit.
> Does somebody has some ideas ?
Does the Cisco box have any means of logging an hour's worth of traffic? If not, can you enable the AccessLogValve in each Tomcat?
What generates the POSTs? If it's JavaScript on the page, is it possible it's broken under some odd conditions? Is it possible that some users are double-clicking some button on the browser, causing a request to be fired off, then quickly abandoned for another?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.