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?
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
>