Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of heabdogg@gmail.com designates
 64.233.170.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=n2jksw4Wg9Dcex+6I2XZtCAFt+DIq5G+az+4WOCjxKLJ0VoykON14OoEa3FQUiFkrob3v7o0Km5VqQ1kiPYPw+puqL+CATnhWJS5782Cj/Ibbn1vIp8irh20Zp8hXXa1zRiq14xX5a2PHfrhyw3sZbac06K784pC+PpHuX+OX+A=
Message-ID: <ebb2e83a05030214137ba02f9e@mail.gmail.com>
Date: Wed, 2 Mar 2005 17:13:30 -0500
From: Scott Heaberlin <heabdogg@gmail.com>
Reply-To: Scott Heaberlin <heabdogg@gmail.com>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: Commons HttpClient: HttpClient#setConnectionTimeout
In-Reply-To: <1109799945.7782.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <421CE076.7010307@noaa.gov> <421D333B.9010107@bancbridge.com>
	 <421D7C43.7000505@indra.es>
	 <292e734005022415236cd1194c@mail.gmail.com>
	 <ebb2e83a05030114555770fee@mail.gmail.com>
	 <1109799945.7782.6.camel@localhost.localdomain>

You are exactly right.  eggOnMe = true

Further investigation showed that I was not setting the read (so)
timeout as I thought. Then when I actually *was* setting soTimeout, I
found a bug in our own application that was ignoring the timeout value
from my own configuration - so instead of my expected "quick" timeout,
httpclient was being set to a normal, much longer timeout.  I simply
wasn't waiting long enough for our default timeout value to expire.

Consequently, I opted to do what one of the previous messages in this
thread suggested - utilize HttpMethod::abort() to achieve an absolute
timeout, as our business requirements do not differentiate from
connection timeout or remote read timeout.  For this I have now
utilized a mechanism very similar to httpclient's own
TimeoutController class combined with HttpMethod::abort().  This
approach works wonderfully - ending the http operation regardless of
the state of the connection or read operations.

Thanks a bunch - and sorry for the confusion.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org