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_at_Sun.COM> wrote:
>
>> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
>> Subject: Re: [Jersey] jersey-apache-client connection pool
>> configuration
>> To: users_at_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_at_acadiasoft.com>
>> wrote:
>>>
>>>> From: Alex Sherwin <alex.sherwin_at_acadiasoft.com>
>>>> Subject: Re: [Jersey] jersey-apache-client
>> connection pool configuration
>>>> To: users_at_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_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>