Paul,
Thanks for the response. I looked at the source for ApacheHttpClientHandler and I totally see what's going on now.
Is a request-specific timeout something you would consider for a future release?
Do you have an idea about how the change would be implemented? Do you envision it being a relatively simple change? Is it something a newcomer might be able to contribute, or at least help with?
Thanks,
Mike
--- On Tue, 6/8/10, Paul Sandoz <Paul.Sandoz@Sun.COM> wrote:
> From: Paul Sandoz <Paul.Sandoz@Sun.COM>
> Subject: Re: [Jersey] jersey-apache-client connection pool configuration
> To: users@jersey.dev.java.net
> Date: Tuesday, June 8, 2010, 1:57 AM
> Hi Mike,
>
> As you are doing you can set the read timeout on the Client
> properties:
>
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/client/Client.html#setReadTimeout%28java.lang.Integer%29
>
> The Apache HTTP client will take this value and set it on
> the HttpMethodParams of the HttpMethod.
>
> // Set the read timeout
> final Integer readTimeout =
> (Integer)props.get(ApacheHttpClientConfig.PROPERTY_READ_TIMEOUT);
> if (readTimeout != null) {
>
> methodParams.setSoTimeout(readTimeout);
> }
>
> So it is up to the Apache HTTP client as to how it manages
> that w.r.t. multiple threads etc.
>
> This property is not currently one that you can set
> per-request or per-WebResource or when building a request.
> Currently it is not possible to override with properties on
> a WebResource, it is something we have looked into but never
> got around to fully implementing it.
>
> The only work around i can think of at the moment is to
> create two Client instances with separate read time out
> values. Not particular efficient.
>
> Paul.
>
> On Jun 8, 2010, at 12:01 AM, Mike Boyers wrote:
>
> > Alex,
> >
> > Thanks - your response has been very helpful.
> >
> > Yes, configuring the poolsize in the way you described
> will work for me.
> >
> > I can now also envision how to set the connection
> manager timeout and I also think I can use a
> ClientFilter to record all of the JMX stats I need
> (timeouts, pool timeouts, total requests, durations, etc.)
> >
> > However, I'm now hung up on request-specific
> timeouts.
> >
> > My understanding is that I should declare the Client,
> then allow it to be shared across all threads.
> >
> > The only way I've found to set the request timeout is
> on the shared Client itself, via the setReadTimeout()
> method.
> >
> > So, I can do something similar to what you typed
> initially:
> >
> > httpClient.setReadTimeout(2000);
> > ClientResponse response =
> httpClient.resource("/some/uri").accept(..).get(ClientResponse.class);
> > if (response.getStatus() <= 201) {
> > String entity =
> response.getEntity(String.class);
> > }
> >
> > My concern is one thread trampling on another's
> timeout.
> >
> > I plan on making multiple requests concurrently via a
> java.util.ThreadPoolExecutor's invokeAll() method. So
> I set up a test with an executor where I'm sending 2
> requests concurrently to the same resource. One of
> them has a timeout of 1000ms, the other 9000ms, and I've
> configured the remote resource to not respond with anything
> until 10 seconds, so both of my client requests should time
> out.
> >
> > In my testing, sometimes the behavior is correct, one
> request will timeout after 1000ms and the other after
> 9000ms. But most often, both requests end up with the
> same timeout, whether it be 9000ms or 1000ms, and that's not
> good in my case, since this test is actually pretty close to
> what I'll need to do in production.
> >
> > Is there a "request-specific" way to set a timeout
> that I've overlooked?
> >
> > Thanks,
> > Mike
> >
> > --- On Mon, 6/7/10, Alex Sherwin <alex.sherwin@acadiasoft.com>
> wrote:
> >
> >> From: Alex Sherwin <alex.sherwin@acadiasoft.com>
> >> Subject: Re: [Jersey] jersey-apache-client
> connection pool configuration
> >> To: users@jersey.dev.java.net
> >> Date: Monday, June 7, 2010, 12:48 PM
> >> How are you configuring your
> >> client? I'm using the ApacheHttpClient
> wrapper from
> >> the Jersey libs, and setting up the
> >> MultiTHreadedHttpConnectionManager directly, like
> so:
> >>
> >> connectionManager =
> new
> >> MultiThreadedHttpConnectionManager();
> >>
> >>
> connectionManager.getParams().setDefaultMaxConnectionsPerHost(MAX_CONNECTIONS_PER_HOST);
> >>
> >>
> connectionManager.getParams().setMaxTotalConnections(MAX_TOTAL_CONNECTIONS);
> >>
> >> clientConfig = new
> >> DefaultApacheHttpClientConfig();
> >>
> >>
> clientConfig.getProperties().put(DefaultApacheHttpClientConfig.PROPERTY_PREEMPTIVE_AUTHENTICATION,
> >> Boolean.TRUE);
> >>
> >> httpClient = new
> ApacheHttpClient(new
> >> ApacheHttpClientHandler(new
> HttpClient(connectionManager)),
> >> clientConfig);
> >>
> >> It sounds like this is what you want to do, I
> believe
> >>
> >> Then, to use,
> >>
> >> ClientResponse response =
> >>
> httpClient.resource("/some/uri").accept(..).get(ClientResponse.class);
> >> if (response.getStatus() <= 201) {
> >> String entity =
> response.getEntity(String.class);
> >> }
> >>
> >> Etc
> >>
> >>
> >> On 6/7/2010 12:08 PM, Mike Boyers wrote:
> >>> I'm beginning work on a RESTful api that, in
> order to
> >> fulfill requests, will need to reach out to other
> apis (some
> >> RESTful themselves, some HTTP but not RESTful).
> >>>
> >>> My main requirements for any HTTP requests
> (both
> >> RESTful and non-RESTful) made to other services
> are:
> >>> -Support keep-alives
> >>> -Support connection pooling
> >>> -Support maximum configurable sizes for
> connection
> >> pools
> >>> -Support fail-fast "connection pool timeouts"
> when a
> >> particular pool has reached its maximum configured
> size
> >>> -If a pool grows under load, it needs to
> shrink again
> >> as load decreases
> >>> -Both RESTful and non-RESTful request should
> share the
> >> same connection pools
> >>> -Ability to query for pool sizes and other
> statistics
> >> to expose via JMX
> >>>
> >>> When using Apache's HttpClient in the raw, I
> know I
> >> can accomplish all of these goals. But that
> won't get
> >> me the jersey-client features I'd like to have, so
> I'd like
> >> to consider using the jersey-apache-client for all
> HTTP
> >> requests and just get the non-RESTful responses as
> Strings.
> >>>
> >>> However, I'm not sure how I can configure the
> >> underlying MultiThreadedHttpConnectionManager to
> behave the
> >> way I want. Some of the methods I'm used to
> calling
> >> are:
> >>>
> >>> setDefaultMaxConnectionsPerHost()
> >>> setConnectionTimeout() -- I know this is
> already
> >> supported and know how to configure it
> >>> closeIdleConnections()
> >>> deleteConnections()
> >>>
> >>> And also HttpClientParameter's
> >> setConnectionManagerTimeout() method.
> >>>
> >>> Any ideas?
> >>>
> >>> Thanks,
> >>> Mike Boyers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net
> >>> For additional commands, e-mail: users-help@jersey.dev.java.net
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net
> >> For additional commands, e-mail: users-help@jersey.dev.java.net
> >>
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net
> > For additional commands, e-mail: users-help@jersey.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net
> For additional commands, e-mail: users-help@jersey.dev.java.net
>
>