Http 500 and %b in access log
Tomcat 6: I am seeing Exception in localhost java.net.SocketTimeoutException: Read time out. I looked at the access log and I see tomcat returning Http 500. Only thing in common is that %b (bytes sent) for all the timeouts are 2657. For rest of them where requests are successfull it's less than 2657. Could someone help me understand what %b is for in localhost access logs and if what I am seeing makes sense. Does SocketTimeoutException correspond to ConnectionTimeout in the connector? We tried increasing it but didn't make any difference. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 500 and %b in access log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mohit, On 1/20/2010 12:06 PM, Mohit Anchlia wrote: Tomcat 6: Which specific version, please. Also, what connector(s) are you using. Please provide the configuration for them. Are you using another web server in front of Tomcat? If so, which one, and how are you connecting them (mod_jk, mod_proxy_ajp, mod_proxy_http, etc.)? I am seeing Exception in localhost java.net.SocketTimeoutException: Read time out. I looked at the access log and I see tomcat returning Http 500. Only thing in common is that %b (bytes sent) for all the timeouts are 2657. For rest of them where requests are successful it's less than 2657. Interesting. Do all responses with fewer than 2657 bytes succeed? Do all responses with more than 2656 bytes fail? Please post the entire stack trace of the exception. Could someone help me understand what %b is for in localhost access logs and if what I am seeing makes sense. %b is, as you say, the number of bytes sent (presumably to the client, in the response). Does this always fail with certain clients? If so, which ones? Are these normal web browsers, or are you using a custom client? Does SocketTimeoutException correspond to ConnectionTimeout in the connector? We tried increasing it but didn't make any difference. ConnectionTimeout is how long the connector will wait after a connection is established for the request to come from the client. There really isn't a setting on the standard HTTP connector that will cause a timeout to occur when writing to the connection. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktXT8wACgkQ9CaO5/Lv0PC+wwCgjE73Gni6yEQ9qJYbldBamfUJ +2IAnjgjRVHVoq8Cro2MmrTrjXTXG0jf =B4HZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 500 and %b in access log
On Wed, Jan 20, 2010 at 10:47 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mohit, On 1/20/2010 12:06 PM, Mohit Anchlia wrote: Tomcat 6: Which specific version, please. Also, what connector(s) are you using. Please provide the configuration for them. Are you using another web server in front of Tomcat? If so, which one, and how are you connecting them (mod_jk, mod_proxy_ajp, mod_proxy_http, etc.)? Using CATALINA_BASE: /usr/local/tomcat Using CATALINA_HOME: /usr/local/tomcat Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME: /usr/local/java Server version: Apache Tomcat/6.0.18 Server built: Jul 22 2008 02:00:36 Server number: 6.0.18.0 OS Name:Linux OS Version: 2.6.9-42.0.10.ELhugemem Architecture: i386 JVM Version:1.5.0_08-b03 JVM Vendor: Sun Microsystems Inc. We don't any other web server in front I am seeing Exception in localhost java.net.SocketTimeoutException: Read time out. I looked at the access log and I see tomcat returning Http 500. Only thing in common is that %b (bytes sent) for all the timeouts are 2657. For rest of them where requests are successful it's less than 2657. Interesting. Do all responses with fewer than 2657 bytes succeed? Do all responses with more than 2656 bytes fail? YES 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) 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) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Could someone help me understand what %b is for in localhost access logs and if what I am seeing makes sense. %b is, as you say, the number of bytes sent (presumably to the client, in the response). Does this always fail with certain clients? If so, which ones? Are these normal web browsers, or are you using a custom client? Yes it always fail with desktop clients on the broadband/modem etc.. Basically ones that are using our GUI application. Does SocketTimeoutException correspond to ConnectionTimeout in the connector? We tried increasing it but didn't make any difference. ConnectionTimeout is how long
Re: Http 500 and %b in access log
-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. 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? 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. 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. 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? 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? 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=6 (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. - -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
Re: Http 500 and %b in access log
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=12 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=6 (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
Re: Http 500 and %b in access log
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=12 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=6 (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
Re: Http 500 and %b in access log
-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=12 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. 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 (1) and seeing if the client/server communication fails after 10 seconds. Then, set it to 120 seconds (12) 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
Re: Http 500 and %b in access log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mohit, On 1/20/2010 4:18 PM, Mohit Anchlia wrote: 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. It doesn't look like it: http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html You could always write a filter to capture this information, though the notion of request received and response sent timestamps is a little blurry: your request is never fully-read, so what's the timestamp for that? If the request does complete, do you want the first-byte time or the last-byte time? Or both? Same question for the response. Finally, you can never really know exactly what time certain things happen due to OS buffering, network lag, etc. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktXfk4ACgkQ9CaO5/Lv0PCz5QCgmHtU6bSsxTeTZ+/cXeZgdHAi 2kkAoLOvrdmaBcnMMesMFkAjlJ16Z0Cz =nVpQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 500 and %b in access log
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=12 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 (1) and seeing if the client/server communication fails after 10 seconds. Then, set it to 120 seconds (12) 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
RE: Http 500 and %b in access log
-Original Message- From: Mohit Anchlia [mailto:mohitanch...@gmail.com] Sent: Wednesday, January 20, 2010 5:40 PM To: Tomcat Users List Subject: Re: Http 500 and %b in access log 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. By just opening a Socket and sending HTTP headers. It's not very difficult. Do you know the clients who are sending you these hanging connections? Either way this is a client problem, but it could be either bad code, or malicious code. And if you find it's the latter you should find a another better solution. You really don't need to waste time by writing a test case or trying to see how long the wait is or anything else. It's a client error. So go and investigate and fix that. Also to add that there is only one kind of timeout you can have for a socket in Java and it's a read timeout. The exception is coming because you aren't getting data from the client in a reasonable amount of time. Increasing your wait timeout is a major mistake because all it really does is increase the ease which with someone can DoS you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
