users@jersey.java.net

Creation overhead of client / concurrency issues

From: Jan Algermissen <algermissen1971_at_mac.com>
Date: Mon, 27 Sep 2010 00:28:44 +0200

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.