tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohit Anchlia <>
Subject Re: Http 500 and %b in access log
Date Wed, 20 Jan 2010 20:08:56 GMT
On Wed, Jan 20, 2010 at 11:41 AM, Christopher Schultz
<> wrote:
> Hash: SHA1
> Mohit,
> On 1/20/2010 2:11 PM, Mohit Anchlia wrote:
>>> Server version: Apache Tomcat/6.0.18
>>> We don't any other web server in front
> Okay. What connector(s) are you using? I'm not sure it matters, given
> the other information you've provided.

    <Connector port="8080" protocol="HTTP/1.1"
               redirectPort="8443" />

>>> Interesting. Do all responses with fewer than 2657 bytes succeed? Do all
>>> responses with more than 2656 bytes fail?
>> YES
> Hmm.
>> Please post the entire stack trace of the exception.
>>> SEVERE: Servlet.service() for servlet SwitchServlet threw exception
>>> Read timed out
>>>         at Method)
>>>         at
>>>         at
>>>         at
> I've never see this class before. What is it? In this some kind of
> instrumentation? If so, what happens if you turn it off?

Yes it's Wily that we use to instrument to get the throughput,
response time etc.

> Another interesting thing is that this fails during a read() operation.
> So, your servlet isn't failing to send data to the client, it's failing
> to read the data in the first place.

YES that is correct.

> I'll bet that 2657 bytes is the size of your "500 error" page. Can you
> check that?

> Does your servlet usually emit fewer than 2657 bytes? That's a pretty
> small response for many HTTP requests.

Yes we don't send much data because it's just an acknwoledgment that's
parsed by home grown client application

>>>         at org.apache.coyote.http11.InternalInputBuffer.fill(
>>>         at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(
>>>         at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(
>>>         at org.apache.coyote.http11.InternalInputBuffer.doRead(
>>>         at org.apache.coyote.Request.doRead(
>>>         at org.apache.catalina.connector.InputBuffer.realReadBytes(
>>>         at org.apache.tomcat.util.buf.ByteChunk.substract(
>>>         at
>>>         at
>>>         at
>>>         at
>>>         at
>>>         at
>>>         at
> So, you're copying a byte array from the client. Where are you copying
> it to?

Copying it to byte array.

transmission = IOUtils.toByteArray(request.getInputStream())

>> Yes it always fail with desktop clients on the broadband/modem etc..
>> Basically ones that are using our GUI application.
> So, regular web browsers like Firefox, MSIE, Safari? When you say "GUI
> application" do you mean a web-based application, or do you have
> something else that's running on the client?

Something else which home grown application running on client

>> Is there also a timeout where connection is closed when 'n' secs
>> expire irrespecitve of if the client and server are actively talking
>> to each other.
> That would be the SocketTimeout itself which I don't believe is settable
> through Tomcat's <Connector> configuration. The default socket timeout
> for ServerSocket is 0 (infinity: wait forever) so it must be that this
> default is being changed somewhere along the way.
> It's possible that the <Connector> configurator will pass-through any
> settings onto the socket (I haven't read the code). It would be simple
> to try adding "soTimeout=60000" (that's 60 seconds) to your <Connector>
> configuration and see if that works. Check the logs after startup to see
> if there's any warning that the "soTimeout" attribute didn't match
> anything useful.

It didn't throw warning when I changed it.

> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> Rq0An09fm8L6FT6PYP5KolY6R+li+C3H
> =ZVEw
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message