hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Krugler <kkrugler_li...@transpac.com>
Subject Re: Simulating connection timeout?
Date Tue, 30 Mar 2010 14:06:03 GMT

On Mar 29, 2010, at 1:59pm, KARR, DAVID (ATTSI) wrote:

>> -----Original Message-----
>> From: Ken Krugler [mailto:kkrugler_lists@transpac.com]
>> Sent: Monday, March 29, 2010 1:42 PM
>> To: HttpClient User Discussion
>> Subject: Re: Simulating connection timeout?
>>
>>
>> On Mar 29, 2010, at 1:12pm, Sam Crawford wrote:
>>
>>> Ken - Correct me if I'm wrong, but the mechanism you provided would
>>> test the read timeout rather than a connection timeout.
>>
>> Maybe I misunderstood David, but I thought the connection manager
>> timeout he mentioned was for getting a connection from the connection
>> pool.
>
> I'm no longer certain exactly what this is testing.  I thought the
> following code:
>
>        HttpClientParams    clientParams    = new HttpClientParams();
>        clientParams.setSoTimeout(getReadTimeout());
>
> clientParams.setConnectionManagerTimeout(getConnectionTimeout());
>
>        HttpClient  httpClient  = new HttpClient(clientParams);
>
> Would set the "connection timeout", as opposed to the "read timeout".
> Is this the case, or not?

In the code above you're setting both the socket time (which you're  
calling the read timeout) and the connection manager timeout.

> It appears to be pretty hard to really test this.  I can set a
> non-pingable IP address, and that gives me a "ConnectException", but
> that's not quite the same thing.

Correct. See below for how to test the connection manager timeout.

-- Ken

> I'm about to conclude that the value
> of testing this is less than the trouble required to simulate this.
>
>> If so, then I simulate this using the Jetty support I mentioned by
>> creating a single thread connection pool, make an threaded
>> localhost:<port> request with a handler that takes forever, and then
>> make the main request with a short connection timeout. This should
>> trigger the error.
>>
>> If he's looking for a connection refused error (nobody listening on
>> that port), then I'd do the same thing (set up Jetty, listening on a
>> port like 8089) but make a request to localhost:8090. That way you're
>> not dependent on external configuration for a test.
>>
>> -- Ken
>>
>>>
>>> David - Sub-1ms latency on your intranet is normal (providing the
>>> hosts are within the same location). If you're just looking to test
>>> that the timeout is hit, then I'd try connecting to a host that does
>>> *not* exist (i.e. pick an IP address in your network that does not
>>> ping). This will trigger a connection timeout, as no response will
> be
>>> received. Alternatively, if you have a large regional network, try
>>> connecting to a host in another city/country.
>>>
>>> Thanks,
>>>
>>> Sam
>>>
>>>
>>> On 29 March 2010 20:53, Ken Krugler <kkrugler_lists@transpac.com>
>>> wrote:
>>>>
>>>> On Mar 29, 2010, at 12:31pm, KARR, DAVID (ATTSI) wrote:
>>>>
>>>>> I'm trying to test that my framework code deals appropriately with
>> a
>>>>> connection timeout error.  I'm connecting to another host on our
>>>>> intranet, and I've set the "connectionManagerTimeout" to "1" (1
>> ms).
>>>>> This does not fail.  Is that surprising?  I've also tested the
> read
>>>>> timeout, and that appears to work fine.  Is there something simple
>>>>> I can
>>>>> do that can force a connection timeout?
>>>>
>>>> I don't know what others do, but I run an embedded Jetty server to
>>>> test this
>>>> type of support.
>>>>
>>>>       HttpServer server = new HttpServer();
>>>>       server.addListener(":" + port);
>>>>       HttpContext context = server.getContext("/");
>>>>       context.addHandler(handler);
>>>>       server.start();
>>>>
>>>> Where <handler> is something that extends AbstractHttpHandler
>>>>
>>>> So then it's pretty easy to do things like have a handler that just
>>>> hangs.
>>>>
>>>> -- Ken
>>>>
>>>> --------------------------------------------
>>>> Ken Krugler
>>>> +1 530-210-6378
>>>> http://bixolabs.com
>>>> e l a s t i c   w e b   m i n i n g
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>
>> --------------------------------------------
>> Ken Krugler
>> +1 530-210-6378
>> http://bixolabs.com
>> e l a s t i c   w e b   m i n i n g
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>

--------------------------------------------
Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c   w e b   m i n i n g





---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message