Return-Path: 
 <users-return-96859-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-users-archive@www.apache.org
Received: (qmail 96661 invoked from network); 16 Nov 2008 15:27:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 16 Nov 2008 15:27:40 -0000
Received: (qmail 84502 invoked by uid 500); 16 Nov 2008 15:27:46 -0000
Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org
Received: (qmail 83903 invoked by uid 500); 16 Nov 2008 15:27:45 -0000
Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:users-help@cocoon.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@cocoon.apache.org>
List-Post: <mailto:users@cocoon.apache.org>
Reply-To: users@cocoon.apache.org
List-Id: <users.cocoon.apache.org>
Delivered-To: mailing list users@cocoon.apache.org
Received: (qmail 83892 invoked by uid 99); 16 Nov 2008 15:27:45 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Nov 2008 07:27:45 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates
 216.86.168.183 as permitted sender)
Received: from [216.86.168.183] (HELO mxout-08.mxes.net) (216.86.168.183)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Nov 2008 15:26:23 +0000
Received: from [192.168.0.125] (unknown [82.210.157.165])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 3B28AD05BF
	for <users@cocoon.apache.org>; Sun, 16 Nov 2008 10:26:06 -0500 (EST)
Message-ID: <49203B8C.7030409@tuffmail.com>
Date: Sun, 16 Nov 2008 16:26:04 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Strange Exception with Cocoon2.2
References: 
 <OF5A69AD3B.E07B6DB7-ONC1257503.003D59D9-C1257503.003EBEDE@workflow.at>
In-Reply-To: 
 <OF5A69AD3B.E07B6DB7-ONC1257503.003D59D9-C1257503.003EBEDE@workflow.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Gabriel Gruber pisze:
> 
> Hello,

Hi.

> I am facing a strange issue with our product, which was recently ported
> to cocoon 2.2 and is now in the final stabilization phase. It seems that
> for some reason various exceptions occure on the log which might have
> something to do with servlet service framework or inproper configuration
> of jetty. this particular exception is repoduceable as we get it, when
> driving a seleninium testcase against an embedded jetty/hsqldb
> configuration of our product.
> 
> Interestingly this does not have any bad consequence in the frontend.
> however something seems to go wrong...

<snip/>

> Caused by: java.net.SocketException: Connection reset by peer: socket
> write error
> 
>                 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.mortbay.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:169)
> 
>                 at
> org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:122)
> 
>                 at
> org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:693)
> 
>                 ... 82 more
> 
> Does anyone have a clue, what could be the issue?

I believe the rest of the stack trace is not relevant thus I wouldn't blame SSF or Cocoon in
general. The message "Connection reset by peer: socket write error" suggests more a problem with
Jetty or application accessing jetty. Basically it looks like someone is closing connection too
early so the rest of data cannot be written.

Yet, it's interesting that it does not affect the client and the data it receives.

I would suggest testing this with different clinet/servlet container configuration. Also, does it
happen with responses having 200 (HTTP_OK) status code?


-- 
Grzegorz Kossakowski

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org