Salut,
kawazu wrote:
> Salut Jeanfrancois;
>
> and at first thanks a bunch for your comments on that, much appreciated.
you are welcome!
>
> 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... :/
OK you are using mod_proxy. Can you share you config file? I'm just
curious to to see if that could be the problem.
>
> 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...
>
>
Can you share your domain.xml? If you can't send it publicly, just send
it to jfarcand at apache dot org and I will take a look.
>> 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...
OK let me know what those folks thinks :-)
A+
-- Jeanfrancois
>
> Thanks for your patience, best regards.
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>