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 <mohitanch...@gmail.com> wrote: > On Wed, Jan 20, 2010 at 11:41 AM, Christopher Schultz > <ch...@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-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
