[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-bugdb
Subject:    general/9082: Periodic persistent connections closed after POST
From:       Mike McKnight <mcknight () signalsoftcorp ! com>
Date:       2001-10-27 15:05:31
[Download RAW message or body]


>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 <apbugs@Apache.Org> 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!     ]
 
 

[prev in list] [next in list] [prev in thread] [next in thread]