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 22:39:37 GMT
On Wed, Jan 20, 2010 at 2:00 PM, Christopher Schultz
<chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mohit,
>
> On 1/20/2010 3:08 PM, Mohit Anchlia wrote:
>>     <Connector port="8080" protocol="HTTP/1.1"
>>                connectionTimeout="120000"
>>                maxThreads="300"
>>                redirectPort="8443" />
>
> Okay, so you're using the standard HTTP connector. Is APR involved? I
> notice that your connectionTimeout is 2 minutes: is there a reason to
> increase that timeout from the default 1 minute? 1 minute is a long time
> to wait around for the client to simply make a request.
>
>>> 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.
>
> So... what happens if you take-out the instrumentation? Does the
> exception still occur?
>
>>> I'll bet that 2657 bytes is the size of your "500 error" page. Can you
>>> check that?
>
> Did you check this?
>
>>> 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
>
> Interesting: you have a home-grown client application. I wonder if the
> client application isn't working properly. For instance, if the client
> sends a Content-Length but then doesn't send enough bytes, Tomcat will
> wait for a long time and then throw a SocketTimeoutException. It's
> possible this is happening in this case. If the client doesn't close the
> output stream (from the client to the server) then the server might wait
> forever (until it times out) for the remaining data. Again, check that
> your client is sane.

I suspect the following as you mentioned. Is there a way I can write
small application that simulates this behaviour? How do I write in a
way that content-length goes through but bytes are not sent.

>>> 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())
>
> Ok. You might want to modify the code so that you repeatedly read and
> then report the maximum number of bytes read before the pipe stalls.
> Logging the Content-Length from the request might also prove useful.
>
>>> 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
>
> I would encourage you to use a well-known client such as "wget" to check
> the server behavior: if wget still has problems, then you know that a
> server-side solution is necessary. If wget works with no problems,
> you're client app is probably broken.
>
>> [Tomcat] didn't throw warning when I changed [the soTimeout attribute].
>
> Try setting that to 10 seconds (10000) and seeing if the client/server
> communication fails after 10 seconds. Then, set it to 120 seconds
> (120000) and see if the same error takes 2 minutes. If so, that setting
> is correct, although it won't help you: it will just set the amount of
> time necessary before the server gives up on your client.
>
> Again, I'd really recommend that you check into your client app code so
> make sure it's following the rules.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAktXfO8ACgkQ9CaO5/Lv0PD8kQCfSi4pTOuBgQazu7MMT63kAbFU
> +c4AoJR/5thGws3IFd0KNfO23+2BItYX
> =VvCH
> -----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