On Sep 27, 2010, at 12:25 PM, Jan Algermissen wrote:
> Rephrasing part of the question:
>
> Apparently, when using the Apache HTTP client the HTTP connector is
> 'operated' in a thread safe way:
>
> <quote>
> * If an {_at_link ApacheHttpClientHandler} is not explicitly passed as a
> * constructor or method parameter then by default an instance is
> created with
> * an {_at_link HttpClient} constructed with a {_at_link
> MultiThreadedHttpConnectionManager}
> * instance.
> </quote>
>
> At least for this case, my question can be stripped down to:
>
> Is the Jersey-client implementation around the underlying connector
> thread safe? Given I use Apache HTTP client, could I then create the
> Jersey client instance in a @Singleton EE6 bean?
>
Yes. The instance of Client and WebResource are thread safe as long
the filters are not modified. The underlying implementations using
HttpURLConnection and the ApacheHTTPClient are thread safe.
Paul.
> Thanks,
> Jan
>
>
>
>
>
>
>
> On Sep 27, 2010, at 12:28 AM, Jan Algermissen wrote:
>
>> Hi,
>>
>> I am using the jersey client from within an EE6 application.
>>
>> The safest way to do this is obviously instantiating the client in
>> the context of a stateless session bean. However, this would mean
>> having to construct a single client per request and given the
>> amount of work done during client construction that seems like a
>> rather bad solution.
>>
>> Hence my question: what are the concurrency issues regarding Jersey
>> clients? Is there any concurrency management inside the client at
>> all or does it depend on being called from a single thread only
>> (which I assume)?
>>
>> What are the issues regarding the underlying HTTP client connector
>> implementation chosen? There might by a clean separation between
>> multiple client instances but are there issues once the HTTP
>> request is being made? This includes concurrency issues as well as
>> management of open client connections.
>>
>> Any suggestions? What would be the thing to share across client
>> instances? The configuration maybe?
>>
>> Thanks,
>> Jan
>>
>> P.S. Are there any plans for a client side 'runtime' that could be
>> used to manage the resources (connections, cache) shared by
>> multiple independent client instances? I guess something like this
>> would be the thing to instantiate in a singleton context in an EE6
>> Web app that uses frequent client connections.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>