www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Keller <kel...@bfg.com>
Subject Re: mod_proxy/5972: Proxy cannot connect to many IIS 4.0 sites
Date Sun, 16 Apr 2000 19:30:01 GMT
The following reply was made to PR mod_proxy/5972; it has been noted by GNATS.

From: Ted Keller <keller@bfg.com>
To: Marc Slemko <marcs@znep.com>
Cc: Apache bugs database <apbugs@apache.org>
Subject: Re: mod_proxy/5972: Proxy cannot connect to many IIS 4.0 sites
Date: Sun, 16 Apr 2000 15:27:27 -0400 (EDT)

 Marc,
 
 Latest updates.
 
 I built apache for an AIX 4.3.1 system.  Apache exhibited the same issues
 with support.dell.com - hung there until the connection eventually timed
 out.
 
 I tried going to this site with the tis http-gw.  Noted that it also
 "hung" there until the connections timed out - however, data was returned
 to the client.  Lingering connections stayed inplace until the timeout
 completed.
 
 General timings are as follows..
 
 Client native to support.dell.com via socks5 gateway - 3 seconds
 
 Client (IE5) to support.dell.com via TIS http-gw - 6 seconds
 	(timeouts completed around 9 seconds from page request).
 
 Client (IE5) to support.dell.com with short timeout in buff.c - 50 seconds
 
 Client IE5) to support.dell.com via apache without short timeout -
 never....     Note - same symptoms for both Solaris and AIX
 
 
 Current thoughts....
 
 IIS is breaking protocol.  They do not seem to be sending an EOF at the
 termination of the HTTP 1.x page.  That's bad because it breaks about
 every proxy server out there....
 
 Clients display the data as they get it.  If the eof doesn't occur - they
 timeout out the sessions after the last read.  User does not see impact.
 However, firewalls.... may be hanging long-term connections (Mine seems
 to).
 
 I've attached below a solaris "truss" which shows all system calls - and a
 gdb debug session - stepping through the ap_proxy_send_fb routine.  Both
 show long term hangs during the final read waiting for a timeout to occur
 or an EOF to be received.
 
 Suggestions....
 
 Since this may take awhile for Microsoft to identify and correct the
 problem - and even longer for Internet sites to implement the desired
 service pack level, it seems that we need to implement a short timeout
 variable logic algorithm.  The general crux of the algorithm will be as
 follows:
 
 1. default to some short timeout value - say 10 seconds for a connection.
 this should be configurable.
 
 2. based on prior block reads from a host for that session, calculate the
 connection speed on the completion of each block read.
 
 3. add a small safety factor (local line congestion).
 
 4. modify short timeout value for next read to match session transfer
 speed.
 
 5. If timeout occurs - assume EOF.... terminate the connection.
 
 Feed back any thoughts...
 
 Many thanks
 
 ted keller
 
 
 send(4, " G E T   /   H T T P / 1".., 442, 0)   = 442
 alarm(0)                                        = 300
 alarm(300)                                      = 0
 getsockname(4, 0xFFBED1A8, 0xFFBED2B4, 1)       = 0
 getsockopt(4, 65535, 4104, 0xFFBED2BC, 0xFFBED2B8, 1) = 0
 recv(4, " H T T P / 1 . 1   3 0 2".., 4096, 0)  = 384
 alarm(0)                                        = 300
 unlink("/scratch/apache/Y/i/G/PRwpDwnn92dVl2yo7ZA") Err#2 ENOENT
 alarm(300)                                      = 0
 alarm(0)                                        = 300
 alarm(0)                                        = 0
 alarm(300)                                      = 0
 getsockname(4, 0xFFBEB128, 0xFFBEB234, 1)       = 0
 getsockopt(4, 65535, 4104, 0xFFBEB23C, 0xFFBEB238, 1) = 0
 recv(4, 0xFFBEB61D, 8059, 0)    (sleeping...)
 recv(4, 0xFFBEB61D, 8059, 0)    (sleeping...)  DIED HERE....
 
 
 
 ns2.bfg.com 201# gdb
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "sparc-sun-solaris2.7".
 (gdb) file httpd
 Reading symbols from httpd...done.
 (gdb) break ap_proxy_send_fb
 Breakpoint 1 at 0x29c38: file proxy_util.c, line 498.
 (gdb) run -X
 Starting program: /usr/local/apache-test/sbin/httpd -X
 
 Breakpoint 1, ap_proxy_send_fb (f=0x1027d0, r=0x101b00, c=0x102708)
     at proxy_util.c:498
 498         conn_rec *con = r->connection;
 (gdb) s
 499         int alternate_timeouts = 1; /* 1 if we alternate between soft & hard
  timeouts */
 (gdb) s
 501         total_bytes_rcvd = 0;
 (gdb) s
 502         if (c != NULL)
 (gdb) s
 503             c->written = 0;
 (gdb) s
 518         ap_kill_timeout(r);
 (gdb) s
 ap_kill_timeout (dummy=0x101b00) at http_main.c:1322
 1322        ap_set_callback_and_alarm(NULL, 0);
 (gdb) s
 ap_set_callback_and_alarm (fn=0, x=0) at http_main.c:1220
 1220        if (alarm_fn && x && fn != alarm_fn) {
 (gdb) s
 1224        alarm_fn = fn;
 (gdb) s
 1228        if (child_timeouts) {
 (gdb) s
 1229            old = alarm(x);
 (gdb) s
 1230        }
 (gdb) s
 1242        return (old);
 (gdb) s
 1243    }
 (gdb) s
 ap_kill_timeout (dummy=0x101b00) at http_main.c:1323
 1323        timeout_req = NULL;
 (gdb) s
 1324        timeout_name = NULL;
 (gdb) s
 1325    }
 (gdb) s
 ap_proxy_send_fb (f=0x1027d0, r=0x101b00, c=0x102708) at proxy_util.c:533
 533         if (c == NULL || c->len <= 0 || c->cache_completion == 1.0) {
 (gdb) s
 534             ap_hard_timeout("proxy send body", r);
 (gdb) s
 ap_hard_timeout (name=0xb8858 "proxy send body", r=0x101b00)
     at http_main.c:1304
 1304        timeout_req = r;
 (gdb) s
 1305        timeout_name = name;
 (gdb) s
 1307        ap_set_callback_and_alarm(timeout, r->server->timeout);
 (gdb) s
 ap_set_callback_and_alarm (fn=0x4b860 <timeout>, x=300) at http_main.c:1220
 1220        if (alarm_fn && x && fn != alarm_fn) {
 (gdb) s
 1224        alarm_fn = fn;
 (gdb) s
 1228        if (child_timeouts) {
 (gdb) s
 1229            old = alarm(x);
 (gdb) s
 1230        }
 (gdb) s
 1242        return (old);
 (gdb) s
 1243    }
 (gdb) s
 ap_hard_timeout (name=0xb8858 "proxy send body", r=0x101b00)
     at http_main.c:1309
 1309    }
 (gdb) s
 ap_proxy_send_fb (f=0x1027d0, r=0x101b00, c=0x102708) at proxy_util.c:535
 535             alternate_timeouts = 0;
 (gdb) s
 543         for (ok = 1; ok; ) {
 (gdb) s
 544             if (alternate_timeouts)
 (gdb) s
 548             n = ap_bread(f, buf, IOBUFSIZE);
 (gdb) s
 ap_bread (fb=0x1027d0, buf=0xffbeb560, nbyte=8192) at buff.c:709
 709         if (fb->flags & B_RDERR)
 (gdb) s
 711         if (nbyte == 0)
 (gdb) s
 714         if (!(fb->flags & B_RD)) {
 (gdb) s
 737         nrd = fb->incnt;
 (gdb) s
 739         if (nrd >= nbyte) {
 (gdb) print nbyte
 $1 = 8192
 (gdb) print nrd
 $2 = 133
 (gdb) s
 751         if (nrd > 0) {
 (gdb) s
 757             memcpy(buf, fb->inptr, nrd);
 (gdb) s
 758             nbyte -= nrd;
 (gdb) s
 759             buf = nrd + (char *) buf;
 (gdb) s
 760             fb->incnt = 0;
 (gdb) s
 762         if (fb->flags & B_EOF)
 (gdb) s
 766         if (nbyte >= fb->bufsiz) {
 (gdb) s
 768             i = read_with_errors(fb, buf, nbyte);
 (gdb) s
 read_with_errors (fb=0x1027d0, buf=0xffbeb5e5, nbyte=8059) at buff.c:686
 686         rv = saferead(fb, buf, nbyte);
 (gdb) s
 saferead_guts (fb=0x1027d0, buf=0xffbeb5e5, nbyte=8059) at buff.c:631
 631         if (fb->flags & B_SAFEREAD) {
 (gdb) s
 635             rv = buff_read(fb, buf, nbyte);
 (gdb) s
 buff_read (fb=0x1027d0, buf=0xffbeb5e5, nbyte=8059) at buff.c:287
 287         rv = ap_read(fb, buf, nbyte);
 (gdb) s
 ap_read (fb=0x1027d0, buf=0xffbeb5e5, nbyte=8059) at buff.c:245
 245             rv = read(fb->fd_in, buf, nbyte);
 (gdb) s  - LONG Hang TIME HERE
 
 Program exited normally.
 (gdb) 
 
 On Fri, 14 Apr 2000, Marc Slemko wrote:
 
 > On Fri, 14 Apr 2000, Ted Keller wrote:
 > 
 > > Marc,
 > > 
 > > Restored buff.c to original mode.  Turned off http 1.1 processing in the
 > > browser.  Hit support.dell.com site - browser appears to die (were back to
 > > using default timeouts).
 > 
 > So you mean just going to http://support.dell.com/ ?
 > 
 > Have you tried a more recent version of Apache?
 > 
 > Do other browsers have the same problem?
 > 
 > I'm having trouble reproducing it.
 > 
 > > 
 > > Netstat -n reports 
 > > xxx.xxx.xxx.xxx.59939  143.166.82.190.80    17152      0 64240      0
 > > ESTABLISHED
 > >  
 > > all other connections to that site are in a FIN_WAIT mode.
 > > 
 > > With the buff.c modification, and http 1.1 support turned off, performance
 > > improves to near acceptable. However, we still wait for the connection to
 > > close which never does until the short timeout is reached.
 > > 
 > > Direct connections show this pages loads in about 2 seconds.
 > > With the "fix" page loads in about 30 seconds
 > > Without the "fix" page fails to load.
 > > 
 > > Obviously I like the 2 second loads....
 > > 
 > > 
 > > On Fri, 14 Apr 2000, Marc Slemko wrote:
 > > 
 > > > On 14 Apr 2000, Ted Keller wrote:
 > > > 
 > > > > The following reply was made to PR mod_proxy/5972; it has been noted
by GNATS.
 > > > > 
 > > > > From: Ted Keller <keller@bfg.com>
 > > > > To: submit@bugz.apache.org, apache-bugdb@apache.org
 > > > > Cc:  
 > > > > Subject: Re: mod_proxy/5972: Proxy cannot connect to many IIS 4.0 sites
 > > > > Date: Fri, 14 Apr 2000 18:17:41 -0400 (EDT)
 > > > > 
 > > > >  Further investigations have shown the following....
 > > > >  
 > > > >  1. All pages that are failing are http 1.1 type pages.
 > > > >  
 > > > >  2. IE5 has an option, Use HTTP 1.1 through proxy connections, which,
if
 > > > >  checked, seems to help.  Note - netscape 4 does not have an equivalent
 > > > >  selectable feature.
 > > > 
 > > > What if you disable all HTTP/1.1 support in IE?
 > > > 
 > > > >  
 > > > >  3. A modification in buff.c as follows... forces "short" timeouts for
 > > > >  sites that do NOT close connections at the end of a block transmission.
 > > > >  The modification below set this to 8 seconds - this should really be
a
 > > > >  configurable parameter.
 > > > >  
 > > > >  With these, we are starting to see acceptable performance for these
"bad"
 > > > >  sites.
 > > > 
 > > > Refresh my memory; can you give me a URL that exhibits this problem?
 > > > 
 > > 
 > > 
 > > support.dell.com
 > > 
 > > We have also seen this on...
 > > 
 > > www.bell.ca
 > > www.winntmag.com
 > > www.nai.com
 > > 
 > > > Thanks.
 > > > 
 > > 
 > 
 

Mime
View raw message