users@glassfish.java.net

Re: (mod_jk) ClientAbortException again.

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 08 Jul 2008 11:46:29 -0400

Salut,

adding mod_jk in the title to brings the experts :-)

Kristian Rink wrote:
> Hi all;
>
> unfortunately dealing with that friend again:
>
> [...]
> ClientAbortException: java.io.IOException: Connection reset by peer
> at
> org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:412)
> at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:417)
> at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:339)
> at org.apache.coyote.tomcat5.OutputBuffer.writeBytes(OutputBuffer.java:437)
> at org.apache.coyote.tomcat5.OutputBuffer.write(OutputBuffer.java:424)
> at
> org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.java:145)
> at
> de.planconnect.webui.projekt.controllers.WebUIDocumentController.getPlanList(WebUIDocumentController.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> [...]
>

This exception happens when the client close the connection before the
WebContainer has finished writing the response. Do you have a
firewall/proxy in between GlassFish and your client that can decide to
close the connection? You are using mod_jk right? Grizzly doesn't seems
to be in the picture here....


>
>
> Scenario: Downloading a > 10 MB file using a Spring MVC controller in a
> webapp inside glassfish v2u2, fronted by an apache2 installation. I've
> earlier been hinted that this possibly is just an MSIE issue not causing
> any trouble, but in this case however, it does, and it does keep the
> file from being transmitted correctly. As far as I see things (i.o.w. as
> far as our network infrastructure is involved), there's no real reason
> for this issue. On the customer side, in this (worst) case, there's
> however no administrator / system maintainer at hand to check what could
> possibly cause this problem.

I'm not an expert with mod_jk, so I cannot help as I would like. There
might be a time out valu on the Apache side?


>
> Trying to get this sorted out, could this be caused by
>
> - bandwidth problems on our side,
>
> - issues in our application logic (i.e. local file access),
>
> - configuration of application server and proxy - does
> "ClientAbortException" mean the _client_ ,i.o.w. the end users browser,
> or just the reverse apache2 proxy being "client" to the backend system,
> has caused a "Connection reset by peer"?

It is really because the connection get closed between the client and
the server, and the server was in the process of writing the response.

Hope that help.

A+

-- Jeanfrancois



>
> Feels like clutching at straws, but I am running out of ideas on that
> one... :/
>
> Thanks in advance for any comments, best regards...
> Kristian
>
>
>