Paul,
Thanks - that workaround does indeed work and alleviates the timeout "clobbering" issue I mentioned previously. I will go with that approach for now.
Thanks to everyone who has responded - it's been very helpful.
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, 11:45 AM
> Hi Mike,
>
> Pavel, can you share details on the work we did for
> WebResource
> properties and copy on write stuff?
>
> In the interim i think there is a workaround.
>
> WebResource r = ...
>
> r.addFilter(new ReadTimeOut(1000));
>
>
> public class ReadTimeOut extends ClientFilter {
> private final int t;
>
> public ReadTimeOut(int t) {
> this.t = t;
> }
>
> public ClientResponse
> handle(ClientRequest cr) {
>
> cr.getProperties().put(ClientConfig.PROPERTY_READ_TIMEOUT,
> t);
> return
> getNext().handle(cr);
> }
> }
>
> The above should work as long as you do not set the
> PROPERTY_READ_TIMEOUT on the Client.
>
> Paul.
>
> On Jun 8, 2010, at 4:56 PM, Mike Boyers wrote:
>
> > 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
> >>
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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
>
>