tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohit Anchlia <mohitanch...@gmail.com>
Subject Re: Http 500 and %b in access log
Date Wed, 20 Jan 2010 21:18:08 GMT
On the same note. Is there a way to log in access log at what time the
request was received and time response was sent? I am planning to add
more debug to see how long it waits before timing out.

On Wed, Jan 20, 2010 at 12:08 PM, Mohit Anchlia <mohitanchlia@gmail.com> wrote:
> On Wed, Jan 20, 2010 at 11:41 AM, Christopher Schultz
> <chris@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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"
>               connectionTimeout="120000"
>               maxThreads="300"
>               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
>>>> java.net.SocketTimeoutException: Read timed out
>>>>         at java.net.SocketInputStream.socketRead0(Native Method)
>>>>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>>>         at java.io.FilterInputStream.read(FilterInputStream.java:111)
>>>>         at com.wily.introscope.agent.probe.net.ManagedSocketInputStream.read(ManagedSocketInputStream.java:214)
>>
>> 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(InternalInputBuffer.java:746)
>>>>         at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:776)
>>>>         at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:116)
>>>>         at org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:705)
>>>>         at org.apache.coyote.Request.doRead(Request.java:428)
>>>>         at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:304)
>>>>         at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:405)
>>>>         at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:327)
>>>>         at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:162)
>>>>         at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
>>>>         at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
>>>>         at org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:218)
>>>>         at com.intuit.engine.efp.efe.efileswitch.SwitchServlet.doPostOrGet(SwitchServlet.java:174)
>>>>         at com.intuit.engine.efp.efe.common.servlet.BaseServlet.doPost(BaseServlet.java:48)
>>
>> 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAktXXFsACgkQ9CaO5/Lv0PCZAACfeJMBprxz6/hwoOmp9PXA8VwN
>> Rq0An09fm8L6FT6PYP5KolY6R+li+C3H
>> =ZVEw
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message