Re: ClientAbortException / Broken Pipe?!
Frank; first off, thanks a load for your reply, much appreciated. [Frank W. Zammetti [EMAIL PROTECTED] @ Tue, 14 Aug 2007 11:02:42 -0400 (EDT)] Have you noticed if this affects IE users and Firefox users equally? I ask because there's a known issue (that I've never seen an actual answer to) where IE causes these exceptions frequently with no ill effect to anything (other than the overhead of handling the exception in the VM on the server). I am not sure on that, gonna check that in order to see whether or not you're about to get your box of donuts. ;) However, seriously this is a rather bad thing as I am convinced most of our users to possibly make use of a default web browser on their system, having no idea what a browser is, at all... On the other side, having the file transmission terminated / corrupted surely isn't what I would call no ill effect... ;) Does anyone have a smart idea how to compensate for this issue? Thanks in advance and best regards, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
ClientAbortException means the user canceled the download (the 'client aborted'). There is nothing you can do about that on the server. Ronald. On Tue Aug 14 15:57:25 CEST 2007 Tomcat Users List users@tomcat.apache.org wrote: Folks; still messing around with an error like this: In our system, we offer customers a service to download files using a servlet. Some weeks ago (more or less when I considered switching to tomcat 6.0), the following error frequently started to show up in my log files: ... java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:619) 14.08.2007 15:38:34 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 ... whereas I see a ClientAbortException caught by my applications exception handling mechanism. So far, I haven't been able to track this down, that's why I am kindly asking you for your skilled advice. What did I do so far trying to get hold of this: - Tomcat runs on a machine in the LAN, fronted by an apache2 httpd. - The error does appear both running tomcat 6.0.13 and 5.5.23. - I initially was using mod_jk 1.2.29 and switched to mod_proxy and Proxy/ProxyReverse setup just to make sure, and the error appears no matter whether using mod_jk or mod_proxy. - Right now, I am using apache2 prefork mpm, played around with different mpms just to be sure it's not an error related to apache2 itself, but this also didn't really change anything. - apache2 logging doesn't show any messages whenever such a ClientAbortException is thrown. - Customers, however, reported that whenever such a situation happened, the files downloaded were either 0k sized or corrupted. And I'm whole-heartedly clueless by now :( Is there anything I forgot to double-check? Using the latest JDK, no tcnative, running Ubuntu Linux 6.06.1. Applied pretty much every solution attempt I could come up with using google, including tweaking the HTTP connector setup in server.xml, removing tcnative, using mod_proxy instead of mod_jk - no success. Does anyone around here have any more ideas on how to get hold of this? Thanks loads in advance and bye, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Ronald; [Ronald Klop [EMAIL PROTECTED] @ Wed, 15 Aug 2007 09:56:59 +0200 (CEST)] ClientAbortException means the user canceled the download (the 'client aborted'). There is nothing you can do about that on the server. I thought so. However, there are two things: (a) I was unsure whether, in a proxied environment, a ClientAbortException means download canceled by the actual (external) client or by the proxy server (which is directly accessing the backend tomcat). (b) In none of the cases I watched so far, some user consciously / actively stopped a download in progress - all reported that either the download finished but ended up with an empty / small / corrupted file or an error message showed up - or nothing happened at all. :( I am not really sure who's to blame for that... :/ Thanks for your help, nevertheless, and best regards, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Kristian Rink wrote: Ronald; [Ronald Klop [EMAIL PROTECTED] @ Wed, 15 Aug 2007 09:56:59 +0200 (CEST)] ClientAbortException means the user canceled the download (the 'client aborted'). There is nothing you can do about that on the server. I thought so. However, there are two things: (a) I was unsure whether, in a proxied environment, a ClientAbortException means download canceled by the actual (external) client or by the proxy server (which is directly accessing the backend tomcat). OK, the proxy in your case is a reverse proxy. The exception in the tomcat logs could theretically come from a communication failure back to the reverse proxy, or from a failure from the reverse proxy back to the client=browser. In the latter case, the reverse proxy would not accept any more traffic from the tomcat and thus indirectly lead to the same exception. When using mod_jk, it will log problems during sending back data to the client=browser. That way you would know, on which part of the net the original problem is located. By logging response times in your Apache access log and redundantly in your Tomcat access log (at least until you solved or understood the cause of the problem), you can also find out, how long the response took from the perspective of Apache and of Tomcat, and if the duration is close to some configured timeout interval. The pattern for response times if %D, which means microseconds with Apache httpd and milliseocond swith Tomcat. From the mod_jk log and the access log duration information you might even be able to determine, which requests had the problem (this is not easy and if you've got high load, it's difficult). I would suggest using mod_jk 1.2.25. It will log millisecond timestamps and has a couple further stability improvements. You wrote about version 1.2.29 which does not exist, upgrading should be no problem. JK has a couple of timeouts additionally to the Apache httpd timeout. They are described at http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html (b) In none of the cases I watched so far, some user consciously / actively stopped a download in progress - all reported that either the download finished but ended up with an empty / small / corrupted file or an error message showed up - or nothing happened at all. :( I am not really sure who's to blame for that... :/ I would really try to look at the response handling times, the URLs for which it is happening, the client IPs and User Agent types to check, if there are any obvious patterns. In case you can finally reproduce the problem with low load, you can switch jk log level to debug or even trace. Then the log file will include full packet and header dumps. This is not a good idea for high traffic production though. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Ronald Klop wrote: ClientAbortException means the user canceled the download (the 'client aborted'). There is nothing you can do about that on the server. Yeah, that's the answer you'll find most frequently if you spend time Googling for that exception, but anecdotally you'll find that more times than not, there's no evidence of the browser being closed or the client aborting (pressing Stop) while a page is loading. There's definitely something else going on in a great many cases, and I'm at least happy to know that I'm not alone in not having found the real answer yet : Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Ronald. On Tue Aug 14 15:57:25 CEST 2007 Tomcat Users List users@tomcat.apache.org wrote: Folks; still messing around with an error like this: In our system, we offer customers a service to download files using a servlet. Some weeks ago (more or less when I considered switching to tomcat 6.0), the following error frequently started to show up in my log files: ... java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:619) 14.08.2007 15:38:34 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 ... whereas I see a ClientAbortException caught by my applications exception handling mechanism. So far, I haven't been able to track this down, that's why I am kindly asking you for your skilled advice. What did I do so far trying to get hold of this: - Tomcat runs on a machine in the LAN, fronted by an apache2 httpd. - The error does appear both running tomcat 6.0.13 and 5.5.23. - I initially was using mod_jk 1.2.29 and switched to mod_proxy and Proxy/ProxyReverse setup just to make sure, and the error appears no matter whether using mod_jk or mod_proxy. - Right now, I am using apache2 prefork mpm, played around with different mpms just to be sure it's not an error related to apache2 itself, but this also didn't really change anything. - apache2 logging doesn't show any messages whenever such a ClientAbortException is thrown. - Customers, however, reported that whenever such a situation happened, the files downloaded were either 0k sized or corrupted. And I'm whole-heartedly clueless by now :( Is there anything I forgot to double-check? Using the latest JDK, no tcnative, running Ubuntu Linux 6.06.1. Applied pretty much every solution attempt I could come up with using google, including tweaking the HTTP connector setup in server.xml, removing tcnative, using mod_proxy instead of mod_jk - no success. Does anyone around here have any more ideas on how to get hold of this? Thanks loads in advance and bye, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.19/953 - Release Date: 8/14/2007 5:19 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Kristian Rink wrote: However, seriously this is a rather bad thing as I am convinced most of our users to possibly make use of a default web browser on their system, having no idea what a browser is, at all... On the other side, having the file transmission terminated / corrupted surely isn't what I would call no ill effect... ;) Does anyone have a smart idea how to compensate for this issue? Your right, I must not have read carefully the first time, I didn't realize there was a corrupt download involved here. Thanks in advance and best regards, Kristian Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Just as another tidbit in the pot, I get these errors frequently with Websphere, both with and without a web server in front of it, and also both with and without a proxy involved, so it's definitely not Tomcat-specific, nor is it definitively anything involving a proxy (although both could somehow be contributing factors in this particular case). One thing we did notice is that the problem was more frequent when we started using Dojo... now, I'm not blaming Dojo, but I wonder if maybe its something along the lines of the browser opening a connection to see if a particular JS file is fresh, then determining the local copy is fresh, and instead of properly closing the connection it somehow aborts it incorrectly... that wouldn't in the least surprise me with IE... although you'd expect to see that error all the time, so I don't know, maybe it's the way Dojo's package/import system works. Just an observation though. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Rainer Jung wrote: Kristian Rink wrote: Ronald; [Ronald Klop [EMAIL PROTECTED] @ Wed, 15 Aug 2007 09:56:59 +0200 (CEST)] ClientAbortException means the user canceled the download (the 'client aborted'). There is nothing you can do about that on the server. I thought so. However, there are two things: (a) I was unsure whether, in a proxied environment, a ClientAbortException means download canceled by the actual (external) client or by the proxy server (which is directly accessing the backend tomcat). OK, the proxy in your case is a reverse proxy. The exception in the tomcat logs could theretically come from a communication failure back to the reverse proxy, or from a failure from the reverse proxy back to the client=browser. In the latter case, the reverse proxy would not accept any more traffic from the tomcat and thus indirectly lead to the same exception. When using mod_jk, it will log problems during sending back data to the client=browser. That way you would know, on which part of the net the original problem is located. By logging response times in your Apache access log and redundantly in your Tomcat access log (at least until you solved or understood the cause of the problem), you can also find out, how long the response took from the perspective of Apache and of Tomcat, and if the duration is close to some configured timeout interval. The pattern for response times if %D, which means microseconds with Apache httpd and milliseocond swith Tomcat. From the mod_jk log and the access log duration information you might even be able to determine, which requests had the problem (this is not easy and if you've got high load, it's difficult). I would suggest using mod_jk 1.2.25. It will log millisecond timestamps and has a couple further stability improvements. You wrote about version 1.2.29 which does not exist, upgrading should be no problem. JK has a couple of timeouts additionally to the Apache httpd timeout. They are described at http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html (b) In none of the cases I watched so far, some user consciously / actively stopped a download in progress - all reported that either the download finished but ended up with an empty / small / corrupted file or an error message showed up - or nothing happened at all. :( I am not really sure who's to blame for that... :/ I would really try to look at the response handling times, the URLs for which it is happening, the client IPs and User Agent types to check, if there are any obvious patterns. In case you can finally reproduce the problem with low load, you can switch jk log level to debug or even trace. Then the log file will include full packet and header dumps. This is not a good idea for high traffic production though. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ClientAbortException / Broken Pipe?!
Folks; still messing around with an error like this: In our system, we offer customers a service to download files using a servlet. Some weeks ago (more or less when I considered switching to tomcat 6.0), the following error frequently started to show up in my log files: ... java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:619) 14.08.2007 15:38:34 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 ... whereas I see a ClientAbortException caught by my applications exception handling mechanism. So far, I haven't been able to track this down, that's why I am kindly asking you for your skilled advice. What did I do so far trying to get hold of this: - Tomcat runs on a machine in the LAN, fronted by an apache2 httpd. - The error does appear both running tomcat 6.0.13 and 5.5.23. - I initially was using mod_jk 1.2.29 and switched to mod_proxy and Proxy/ProxyReverse setup just to make sure, and the error appears no matter whether using mod_jk or mod_proxy. - Right now, I am using apache2 prefork mpm, played around with different mpms just to be sure it's not an error related to apache2 itself, but this also didn't really change anything. - apache2 logging doesn't show any messages whenever such a ClientAbortException is thrown. - Customers, however, reported that whenever such a situation happened, the files downloaded were either 0k sized or corrupted. And I'm whole-heartedly clueless by now :( Is there anything I forgot to double-check? Using the latest JDK, no tcnative, running Ubuntu Linux 6.06.1. Applied pretty much every solution attempt I could come up with using google, including tweaking the HTTP connector setup in server.xml, removing tcnative, using mod_proxy instead of mod_jk - no success. Does anyone around here have any more ideas on how to get hold of this? Thanks loads in advance and bye, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Have you noticed if this affects IE users and Firefox users equally? I ask because there's a known issue (that I've never seen an actual answer to) where IE causes these exceptions frequently with no ill effect to anything (other than the overhead of handling the exception in the VM on the server). I'd bet a box of donuts that it only happens for IE users. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, August 14, 2007 9:57 am, Kristian Rink wrote: Folks; still messing around with an error like this: In our system, we offer customers a service to download files using a servlet. Some weeks ago (more or less when I considered switching to tomcat 6.0), the following error frequently started to show up in my log files: ... java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:619) 14.08.2007 15:38:34 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 ... whereas I see a ClientAbortException caught by my applications exception handling mechanism. So far, I haven't been able to track this down, that's why I am kindly asking you for your skilled advice. What did I do so far trying to get hold of this: - Tomcat runs on a machine in the LAN, fronted by an apache2 httpd. - The error does appear both running tomcat 6.0.13 and 5.5.23. - I initially was using mod_jk 1.2.29 and switched to mod_proxy and Proxy/ProxyReverse setup just to make sure, and the error appears no matter whether using mod_jk or mod_proxy. - Right now, I am using apache2 prefork mpm, played around with different mpms just to be sure it's not an error related to apache2 itself, but this also didn't really change anything. - apache2 logging doesn't show any messages whenever such a ClientAbortException is thrown. - Customers, however, reported that whenever such a situation happened, the files downloaded were either 0k sized or corrupted. And I'm whole-heartedly clueless by now :( Is there anything I forgot to double-check? Using the latest JDK, no tcnative, running Ubuntu Linux 6.06.1. Applied pretty much every solution attempt I could come up with using google, including tweaking the HTTP connector setup in server.xml, removing tcnative, using mod_proxy instead of mod_jk - no success. Does anyone around here have any more ideas on how to get hold of this? Thanks loads in advance and bye, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Do I get the box, if I can write a servlet and describe a procedure by which a Firefox user can produce the exception when calling my servlet? Frank W. Zammetti wrote: Have you noticed if this affects IE users and Firefox users equally? I ask because there's a known issue (that I've never seen an actual answer to) where IE causes these exceptions frequently with no ill effect to anything (other than the overhead of handling the exception in the VM on the server). I'd bet a box of donuts that it only happens for IE users. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
When I used the phrase I'd bet a box of donuts, what I should have written was ...and if I'm wrong, it won't be the first time :) Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Tue, August 14, 2007 1:08 pm, Rainer Jung wrote: Do I get the box, if I can write a servlet and describe a procedure by which a Firefox user can produce the exception when calling my servlet? Frank W. Zammetti wrote: Have you noticed if this affects IE users and Firefox users equally? I ask because there's a known issue (that I've never seen an actual answer to) where IE causes these exceptions frequently with no ill effect to anything (other than the overhead of handling the exception in the VM on the server). I'd bet a box of donuts that it only happens for IE users. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ClientAbortException / Broken Pipe?!
Rainer Jung [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Do I get the box, if I can write a servlet and describe a procedure by
which a Firefox user can produce the exception when calling my servlet?
I think that something like (haven't actually tried it myself, mostly
because I have servers with infinite timeouts):
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
response.setContentType(text/plain);
PrintWriter out = response.getWriter();
out.println(Hello World);
out.flush();
try {
Thread.sleep(timeout); // timeout is = the configured timeout
on Apache
} catch(InterruptedException iex) {
//ignore
}
}
should work. If anyone has a more interesting example, I'd love to see it
:).
Frank W. Zammetti wrote:
Have you noticed if this affects IE users and Firefox users equally? I
ask because there's a known issue (that I've never seen an actual answer
to) where IE causes these exceptions frequently with no ill effect to
anything (other than the overhead of handling the exception in the VM on
the server). I'd bet a box of donuts that it only happens for IE users.
Yes, it should have no ill effects, since it is happening where Tomcat is
telling Apache that it is done with the request, so Apache can reuse it for
somebody else.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
