I'd start with tcpdump'ing on the client and server-side. 15 minutes sounds like the connection lifetime was reached. I'd certainly be interested to find squid "losing" a connection. Adrian On Wed, Mar 12, 2008, Ivor.Gibbon@xxxxxxxxxxx wrote: > Amos, > Just a refresher to bring this up again as it's still occurring. > > I'm actually running 2.6.17 not 2.5.17 (typo - sorry). > > Please let me know if there's anything else I can supply to help debug > this. > > Thanks, > Ivor. > > > -----Original Message----- > > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > > Sent: 30 January 2008 21:39 > > To: Gibbon, Ivor - CED > > Cc: squid-users@xxxxxxxxxxxxxxx > > Subject: Re: CTRL-F5 timeout problem > > > > > Generally Squid is working fine, except that users with Internet > > > Explorer (seems not to be a problem in Firefox) sometimes encounter > long > > > delays (15 minutes) when they force a refresh using CTRL-F5 and the > page > > > is truncated when they do get it back. Sometimes the problem occurs > > > immediately, sometimes it may need up to 15 CTRL-f5's before it > occurs. > > > > > > I'm running Squid 2.5.17 on windows 2003 server with three Zopes in > a > > > > Well, there are a LOT of known problems with IE and modern web > servers. If > > its critical for you, try using the latest 2.6 and all the many > > compatibility fixes that have been found and fixed since 2.5. > > > > > load balanced configuration using ICP: > > > *********snippet > > > acl in_knetpool dstdomain knetpool > > > > > > cache_peer 10.110.7.111 parent 8001 9980 no-digest no-netdb-exchange > > > name=port8001 > > > cache_peer 10.110.7.111 parent 8005 9981 no-digest no-netdb-exchange > > > name=port8005 > > > cache_peer 10.110.7.111 parent 8010 9982 no-digest no-netdb-exchange > > > name=port8010 > > > > > > cache_peer_access port8001 allow in_knetpool > > > cache_peer_access port8005 allow in_knetpool > > > cache_peer_access port8010 allow in_knetpool > > > > > > cache_peer_access port8001 deny all > > > cache_peer_access port8005 deny all > > > cache_peer_access port8010 deny all > > > > > > # THE FOLLOWING DIRECTIVE IS NEEDED TO MAKE 'backendpool' RESOLVE TO > > > # THE POOL OF CACHE PEERS. > > > # peer balancing: uncommented next two lines > > > never_direct allow all > > > icp_access allow all > > > *********end snippet > > > > > > The 15 minute timeframe suggested a read_timeout and reducing this > > > parameter to 5 minutes caused the truncated page to be returned in > only > > > 5 minutes. > > > > > > Some judicial use of a packet sniffer suggested that Squid had ICP'd > the > > > Zopes and received the page's entire HTML from a Zope (within 3 > seconds) > > > before starting to deliver it to Internet Explorer. Partway through > > > sending it to IE, Squid had sent a smaller than usual (622 bytes > rather > > > than 4150) http packet to IE (and IE had acknowledged it) and then > no > > > further data was sent until Squid timed out (logged a httpTimeout). > IE > > > then requested other items in the page (CSS, images etc) before > > > displaying a truncated page (HTML truncation matched the last > content > > > from the small data packet sent by squid). > > > > > > Does anyone know why this is happening and what I can do to fix it? > > > > Try a more recent squid, the behaviour will likely be different and we > can > > then trace it through the codebase and possibly fix if its a true bug. > > > > Amos -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
