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.
>
Currently there is only HttpURLConnection, which manages connections
(eg. sharing and keep alive), but the configuration and control is
very poor. So i think we require something better.
What i would like to see is the ability to inject a Client or
WebResource (and view stuff) so the connection management stuff is
hidden, and one could also annotate with policy information or service
information (like you have suggested using DNS for service look up). I
think GlassFish requires a client connection manager (utilizing
Grizzly) that one could configure in the domain.xml of GF. Then web
apps can share client connection management for a GF instance.
Paul.