Salut Jeanfrancois;
and at first thanks a bunch for your comments on that, much appreciated.
Jeanfrancois Arcand schrieb:
>> [...] 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....
Well no, actually not - at least not consciously. Doesn't glassfish
require some tomcat jars to be installed in order to allow for JK
protocol connections? If so, mod_jk is definitely out I guess, at least
unless this doesn't come with gfv2u2 out of the box...
We used to make use of mod_jk when these applications were still running
in tomcat6 but switched to mod_proxy altogether with moving them to
glassfish. About firewall/proxy - yes, there's the apache2/mod_proxy
reverse setup, and there is a border router/firewall which _shouldn't_
mess with this, at least according to its log files and configuration... :/
Another thing however is that we're using Spring MVC in this app, but I
so far am unaware that Spring comes pre-packaged with tomcat code - I'll
better check that, just to make sure...
> 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?
Yes I thought about that as well. Situation however is that it seems to
randomly happen - sometimes just a couple of seconds after transmission
started, sometimes a few minutes after having next to 100 megs pushed
down the line... Our external border has pretty strict timeout
configurations per default which have been raised to more sane levels as
nothing worked initially using this box... :)
> 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.
It does indeed, more things to ponder about. Maybe I'll get across this,
posted the same to an apache2 list, let's see what happens there. I have
seen the same behaviour using tomcat6 both along with mod_proxy and
mod_jk for that matters... First thing now is I'll make completely sure
that mod_jk is disabled and not in use for that anymore. And then I'll
see what else to do...
Thanks for your patience, best regards.
Kristian