> -----Original Message-----
> From: Ken Krugler [mailto:[email protected]]
> 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?
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. 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 <[email protected]>
> > 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
> --------------------------------------------
> 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: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
