Return-Path: X-Original-To: apmail-httpd-users-archive@www.apache.org Delivered-To: apmail-httpd-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 04A79DBC3 for ; Tue, 14 Aug 2012 06:43:03 +0000 (UTC) Received: (qmail 76882 invoked by uid 500); 14 Aug 2012 06:42:59 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 76799 invoked by uid 500); 14 Aug 2012 06:42:59 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 76790 invoked by uid 99); 14 Aug 2012 06:42:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 06:42:59 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gouin.ivan@gmail.com designates 74.125.82.173 as permitted sender) Received: from [74.125.82.173] (HELO mail-we0-f173.google.com) (74.125.82.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 06:42:52 +0000 Received: by weyz53 with SMTP id z53so45857wey.18 for ; Mon, 13 Aug 2012 23:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dzgpJmUi86DwYcs4hKWrmbpneRsBHqbkJWZnVDr11wA=; b=nKU+ecBt1r+0eFlfEoLgAAwdiA9BiIZk5MpZ6pxLlckMPGiSeW9lJ19ZE1kxj3THoK NScfWMsKYvKuNNhaaRMWV+IKx7fq62/fqKQi0bpojX4s4Aco5fAnr+3Lltb3rAgiy0Jm iroJOZAAmZbof1ggdHvC67khJU9XKWBwWqbb5aQH+7tFVV4lkiPdEgoEnbM5Etxe/yYY Q/BVqrq8WbvDA11Hr1NJYcLH642tyGrztxhhrX4NUr7IfZSkOObUJsAxC5AVYzuTY4RJ CwkaC+eBZEBbrudwPIg32lTUsAmZhiZ09iBorRmb4ujLlkIR0PZ73Z4M6uDR7bF1gljG 3Gvw== MIME-Version: 1.0 Received: by 10.216.241.202 with SMTP id g52mr8101369wer.212.1344926552476; Mon, 13 Aug 2012 23:42:32 -0700 (PDT) Received: by 10.180.82.133 with HTTP; Mon, 13 Aug 2012 23:42:32 -0700 (PDT) In-Reply-To: <50278F72.6050509@kippdata.de> References: <500FB634.4050401@kippdata.de> <501BEEFC.9010905@kippdata.de> <50278F72.6050509@kippdata.de> Date: Tue, 14 Aug 2012 08:42:32 +0200 Message-ID: From: ivan Gouin To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=e0cb4e43d0a968cce204c7341d24 Subject: Re: [users@httpd] How to debug 70014 and 70007 errors --e0cb4e43d0a968cce204c7341d24 Content-Type: text/plain; charset=UTF-8 Hi Rainer, Keep Alive Timeout wasn't set on my config But its default value of 5 seconds was the reason why the connection closed. In fact the root cause is the behavior of the CXF client who didn't take care of the close announcement of this connection. We're trying to fix this issue but setting the timeout higher solve is a workaround for now. Thank for your help. Ivan On 12 August 2012 13:11, Rainer Jung wrote: > On 08.08.2012 16:20, ivan Gouin wrote: > >> Hi, >> >> Here's more information about my issue: >> >> Here i will call >> user : the application who post the request. >> apache : the httpd server who receive request from the client and send >> them to tomcat >> tomcat: the web server tomcat, a Web Service application >> >> Versions >> user : Apache CXF client 2.2.9 >> apache: httpd 2.2.17 (tried a 2.2.22 too) >> tomcat: 6.0.26 (jdk1.6.0_24) >> >> Here's the post request send by user ( * are for anonymise) >> >> POST /***/***/ws/v2?test HTTP/1.1 >> Content-Type: text/xml; charset=UTF-8 >> SOAPAction: "" >> Authorization: Basic Z3ZkMHRhb2FwcDpkbmVlc3cyYQ== >> Accept: */* >> User-Agent: Apache CXF 2.2.9 >> Content-Length: 304 >> Host: *** >> Connection: Keep-Alive >> >> > xmlns:soap="http://schemas.**xmlsoap.org/soap/envelope/ >> ">************************** >> >> Start at 11:56:57 >> Between 11:56:57.5357 and 11:56:58:4784: 4 request pass OK >> >> Here's the sequence after that : (Time is of tomcat seem too be a little >> shifted, user and apache are on the same host) >> >> 11:56:58.4817 user : POST request >> *11:56:58.**459722tomcatTCP55150300 > 41323 [PSH, ACK] Seq=3187 Ack=3818 >> Win=22400 Len=485 TSval=345704305 TSecr=749474400 (HTTP 200)* >> 11:56:58.**491981apacheTCP55150300 > 41323 [PSH, ACK] Seq=3187 Ack=3818 >> >> Win=22400 Len=485 TSval=345704305 TSecr=749474400 (HTTP 200) >> 11:56:58.492251userHTTP/**XML594HTTP/1.1 200 OK >> > > Did this packet contain the full response? > > *11:56:58.**501457tomcatTCP6641323 > 50300 [ACK] Seq=3818 Ack=3672 >> Win=15872 Len=0 TSval=749474449 TSecr=345704305* >> 11:56:58.**531503apacheTCP6641323 > 50300 [ACK] Seq=3818 Ack=3672 >> Win=15872 Len=0 TSval=749474449 TSecr=345704305 >> 11:56:58.585937userTCP6045501 > 80 [ACK] Seq=2893 Ack=3948 Win=49640 Len=0 >> > > 5 seconds pause > > *11:57:03.492499userTCP5480 > 45501 [FIN, ACK] Seq=3948 Ack=2893 >> Win=16640 Len=0* >> > > KeepAlive Timeout 5 seconds configured for Apache? > > 11:57:03.494663userTCP6045501 > 80 [ACK] Seq=2893 Ack=3949 Win=49640 Len=0 >> 11:57:08.694657userTCP335[TCP segment of a reassembled PDU] >> 11:57:08.694703userTCP5480 > 45501 [RST] Seq=3949 Win=0 Len=0 >> >> 11:57:08.694661userHTTP/**XML358POST /*/*/ws/v2?test HTTP/1.1 >> 11:57:08.694763userTCP5480 > 45501 [RST] Seq=3949 Win=0 Len=0 >> *11:57:18.**466178tomcatTCP6650300 > 41323 [FIN, ACK] Seq=3672 Ack=3818 >> Win=22400 Len=0 TSval=345724311 TSecr=749474449* >> 11:57:18.**498510apacheTCP6650300 > 41323 [FIN, ACK] Seq=3672 Ack=3818 >> Win=22400 Len=0 TSval=345724311 TSecr=749474449 >> *11:57:18.**508720tomcatTCP6641323 > 50300 [ACK] Seq=3818 Ack=3673 >> Win=15872 Len=0 TSval=749494456 TSecr=345724311* >> 11:57:18.**538771apacheTCP6641323 > 50300 [ACK] Seq=3818 Ack=3673 >> >> Win=15872 Len=0 TSval=749494456 TSecr=345724311 >> >> What make me mad is why apache send a FIN/ACK closing the communication?? >> Is there a time out somewhere? >> This seems to happen about 5 second after the last ACK >> Or 6 second the opening of the socket ( at 11:56:57.53) >> > > I guess its the Keep Alive Timeout of 5 seconds configured for Apache. > Check configuration. > > This should not produce a problem in itself. A client that observes a > closed connection when trying to send a follow on request should > transparently start a new connection. > > Regards, > > Rainer > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: users-unsubscribe@httpd.**apache.org > For additional commands, e-mail: users-help@httpd.apache.org > > --e0cb4e43d0a968cce204c7341d24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rainer,=C2=A0

Keep Alive Timeout wasn't= set on my config=C2=A0
But its default value of 5 seco= nds=C2=A0was the reason why the connection closed.=C2=A0
<= br>
In fact the root cause is the=C2=A0behavior=C2=A0of the CXF client who= didn't take care of the close announcement of this connection.

We're trying to fix this issue but setting the timeou= t higher solve is a workaround for now.

Thank for your help.
Ivan


On 12 August 2012 13:11, Rainer Jung <rainer= .jung@kippdata.de> wrote:
On 0= 8.08.2012 16:20, ivan Gouin wrote:
Hi,

Here's more information about my issue:

Here i will call
user : the application =C2=A0who post the request.
apache : the httpd server who receive request from the client and send
them to tomcat
tomcat: the web server tomcat, a Web Service application

Versions
user : Apache CXF client 2.2.9
apache: httpd 2.2.17 (tried a 2.2.22 too)
tomcat: 6.0.26 (jdk1.6.0_24)

Here's the post request send by user ( * are for anonymise)

POST /***/***/ws/v2?test HTTP/1.1
Content-Type: text/xml; charset=3DUTF-8
SOAPAction: ""
Authorization: Basic Z3ZkMHRhb2FwcDpkbmVlc3cyYQ=3D=3D
Accept: */*
User-Agent: Apache CXF 2.2.9
Content-Length: 304
Host: ***
Connection: Keep-Alive

<soap:Envelope
xmlns:soap=3D"http://schemas.xmlsoap.org/soap/envelope/"&= gt;************************</soap:Envelope>

Start at 11:56:57
Between 11:56:57.5357 and 11:56:58:4784: 4 request pass OK

Here's the sequence after that : (Time is of tomcat seem too be a littl= e
shifted, user and apache are on the same host)

11:56:58.4817 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0user : POST request<= br>
*11:56:58.459722tomcatTCP55150300 > 41323 [PSH, ACK] Seq=3D3187 A= ck=3D3818
Win=3D22400 Len=3D485 TSval=3D345704305 TSecr=3D749474400 (HTTP 200)*
11:56:58.491981apacheTCP55150300 > 41323 [PSH, ACK] Seq=3D3187 Ac= k=3D3818

Win=3D22400 Len=3D485 TSval=3D345704305 TSecr=3D749474400 (HTTP 200)
11:56:58.492251userHTTP/XML594HTTP/1.1 200 OK

Did this packet contain the full response?

*11:56:58.501457tomcatTCP6641323 > 50300 [ACK] Seq=3D3818 Ack=3D3= 672
Win=3D15872 Len=3D0 TSval=3D749474449 TSecr=3D345704305*
11:56:58.531503apacheTCP6641323 > 50300 [ACK] Seq=3D3818 Ack=3D36= 72
Win=3D15872 Len=3D0 TSval=3D749474449 TSecr=3D345704305
11:56:58.585937userTCP6045501 > 80 [ACK] Seq=3D2893 Ack=3D3948 Win=3D496= 40 Len=3D0

5 seconds pause

*11:57:03.492499userTCP5480 > 45501 [FIN, ACK] Seq=3D3948 Ack=3D2893
Win=3D16640 Len=3D0*

KeepAlive Timeout 5 seconds configured for Apache?

11:57:03.494663userTCP6045501 > 80 [ACK] Seq=3D2893 Ack=3D3949 Win=3D496= 40 Len=3D0
11:57:08.694657userTCP335[TCP segment of a reassembled PDU]
11:57:08.694703userTCP5480 > 45501 [RST] Seq=3D3949 Win=3D0 Len=3D0

11:57:08.694661userHTTP/XML358POST /*/*/ws/v2?test HTTP/1.1
11:57:08.694763userTCP5480 > 45501 [RST] Seq=3D3949 Win=3D0 Len=3D0
*11:57:18.466178tomcatTCP6650300 > 41323 [FIN, ACK] Seq=3D3672 Ac= k=3D3818
Win=3D22400 Len=3D0 TSval=3D345724311 TSecr=3D749474449*
11:57:18.498510apacheTCP6650300 > 41323 [FIN, ACK] Seq=3D3672 Ack= =3D3818
Win=3D22400 Len=3D0 TSval=3D345724311 TSecr=3D749474449
*11:57:18.508720tomcatTCP6641323 > 50300 [ACK] Seq=3D3818 Ack=3D3= 673
Win=3D15872 Len=3D0 TSval=3D749494456 TSecr=3D345724311*
11:57:18.538771apacheTCP6641323 > 50300 [ACK] Seq=3D3818 Ack=3D36= 73

Win=3D15872 Len=3D0 TSval=3D749494456 TSecr=3D345724311

What make me mad is why apache send a FIN/ACK closing the communication?? Is there a time out somewhere?
This seems to happen about 5 second after the last ACK
Or =C2=A06 second the opening of the socket ( at 11:56:57.53)

I guess its the Keep Alive Timeout of 5 seconds configured for Apache. Chec= k configuration.

This should not produce a problem in itself. A client that observes a close= d connection when trying to send a follow on request should transparently s= tart a new connection.

Regards,

Rainer



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




--e0cb4e43d0a968cce204c7341d24--