Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 17156 invoked from network); 8 Mar 2010 12:05:36 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Mar 2010 12:05:36 -0000 Received: (qmail 51220 invoked by uid 500); 8 Mar 2010 12:05:13 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 51198 invoked by uid 500); 8 Mar 2010 12:05:13 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 51190 invoked by uid 99); 8 Mar 2010 12:05:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Mar 2010 12:05:13 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.163.196.105] (HELO nyx.xs4all.nl) (83.163.196.105) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Mar 2010 12:05:10 +0000 Received: from saturn.qcg.lan ([192.168.99.10]) by nyx.xs4all.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NobhW-00082H-EI for river-dev@incubator.apache.org; Mon, 08 Mar 2010 13:04:46 +0100 Message-ID: <4B94E7DE.4060505@qcg.nl> Date: Mon, 08 Mar 2010 13:04:46 +0100 From: Sim IJskes - QCG Organization: Quality Consultancy Group b.v. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: river-dev@incubator.apache.org Subject: Re: time until error References: <4B94DCC0.9020901@qcg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom Hobbs wrote: > I don't know where you'd find any official documentation on this, but in my > experience the delay has been the TCP timeout. > > If you already have the proxy then you must wait for the transport > layer/protocol to decide that it can't service your request. Ok, this will mean the attempt will persist up to 9 minutes, solaris 2.2 cuts it to 2 minutes. (according to Stevens). > I'm not sure about another other versions or OSs. linux, man 7 tcp, says: 11 to 30 minutes. > Of course, I might be wrong... :-) Me too. :-) That time is too long for failover isn't it? Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397