Received: (qmail 61507 invoked by uid 501); 27 Oct 2001 15:05:31 -0000 Message-Id: <20011027150531.61506.qmail@apache.org> Date: 27 Oct 2001 15:05:31 -0000 From: Mike McKnight Reply-To: mcknight@signalsoftcorp.com To: submit@bugz.apache.org Subject: Periodic persistent connections closed after POST X-Send-Pr-Version: 3.110 >Number: 9082 >Category: general >Synopsis: Periodic persistent connections closed after POST >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Wed Dec 12 12:40:07 PST 2001 >Closed-Date: >Last-Modified: >Originator: mcknight@signalsoftcorp.com >Release: 1.3.4 >Organization: apache >Environment: SunOS host1 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-6 >Description: We have some HTTP/1.1 persistent connections that remain open for a long while accessing the JRun servlet engine. Requests come in on an infrequent basis. Periodically, I see a message in the error_log like the following: [info][client x.x.x.x] stopped connection before request completed I need to understand what this message means. I know what it does, it closes the socket write after a POST. How can this be prevented? Is this a known bug? Looking at the snoop trace of this here are the following two packets: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 2933 arrived at 23:39:5.73 ETHER: Packet size = 465 bytes ETHER: Destination = x, Sun ETHER: Source = x, ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 451 bytes IP: Identification = 43678 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 64 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = bbe2 IP: Source address = 192.168.61.69, 192.168.61.69 IP: Destination address = 192.168.61.70, 192.168.61.70 IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 59028 TCP: Destination port = 80 (HTTP) TCP: Sequence number = 1952749920 TCP: Acknowledgement number = 3065128801 TCP: Data offset = 20 bytes TCP: Flags = 0x18 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 1... = Push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 32768 TCP: Checksum = 0xe5ef TCP: Urgent pointer = 0 TCP: No options TCP: HTTP: ----- HyperText Transfer Protocol ----- HTTP: HTTP: POST /lm/wli HTTP/1.1 HTTP: User-Agent: Removed Company Info/1.0 HTTP: Host: 192.168.61.70:80 HTTP: Connection: Keep-Alive HTTP: Content-Type: text/xml HTTP: Content-Length: 240 HTTP: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 2934 arrived at 23:39:5.74 ETHER: Packet size = 54 bytes ETHER: Destination = x, ETHER: Source = y ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 23488 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 4d5b IP: Source address = 192.168.61.70, 192.168.61.70 IP: Destination address = 192.168.61.69, 192.168.61.69 IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 80 TCP: Destination port = 59028 TCP: Sequence number = 3065128801 TCP: Acknowledgement number = 1952750331 TCP: Data offset = 20 bytes TCP: Flags = 0x11 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...1 = Fin TCP: Window = 8760 TCP: Checksum = 0xe68e TCP: Urgent pointer = 0 TCP: No options TCP: HTTP: ----- HTTP: ----- HTTP: HTTP: "" HTTP: >How-To-Repeat: I have been unable to reproduce in a controlled test environment. This only happens in our live deployed network at the customer site. >Fix: >Release-Note: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]