You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kristian Rink <kr...@zimmer428.net> on 2007/08/14 15:57:25 UTC

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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.

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: fzammetti@hotmail.com
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Kristian Rink <kr...@zimmer428.net>.
Frank;

first off, thanks a load for your reply, much appreciated.


["Frank W. Zammetti" <fz...@omnytex.com> @ 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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Bill Barker <wb...@wilshire.com>.
"Rainer Jung" <ra...@kippdata.de> wrote in message 
news:46C1E189.5090207@kippdata.de...
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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 
> <us...@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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> 
> 
> ------------------------------------------------------------------------
> 
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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 <ro...@base.nl> @ 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> 
> 
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Rainer Jung <ra...@kippdata.de>.
Kristian Rink wrote:
> Ronald;
> 
> [Ronald Klop <ro...@base.nl> @ 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Kristian Rink <kr...@zimmer428.net>.
Ronald;

[Ronald Klop <ro...@base.nl> @ 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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: ClientAbortException / Broken Pipe?!

Posted by Ronald Klop <ro...@base.nl>.
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 <us...@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: kawazu@jabber.ccc.de * 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>