On Wed, Jan 20, 2010 at 2:00 PM, Christopher Schultz <ch...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
