users@jersey.java.net

[Jersey] Re: Thread and Performance Considerations of Jersey Client 2.x

From: Russ Baker <rbaker_at_ghx.com>
Date: Thu, 31 Oct 2013 19:53:58 +0000

Thanks Gili. JERSEY-2186 has been created.

Regards,

Russ

From: cowwoc [mailto:cowwoc_at_bbs.darktech.org]
Sent: Wednesday, October 30, 2013 2:05 PM
To: users_at_jersey.java.net
Subject: [Jersey] Re: Thread and Performance Considerations of Jersey Client 2.x

Russ,

    Check if someone else filed a bug report about that. If not, create one yourself (and share the link on the list).

Gili

On 30/10/2013 3:34 PM, Russ Baker wrote:
I was actually pretty disappointed in the way that Jersey handled multi-threading. We ran into a number of issues and found that we had to instrument the byte code to use the Jersey client in a multi-threaded environment.

We found that Jersey was not using what the HTTPClient had recommended for Per User/Per Thread state management http://hc.apache.org/httpcomponents-client-4.2.x/tutorial/html/statemgmt.html so when we had to instrument the code, we had to add a local context with a BasicCookieStore to the client and then execute the call. If we did not do this, we found that cookies were shared between each request. We found this to be true in Jersey 1.x as well as Jersey 2.x.

Basically what we ended up doing was to reuse the HttpClient as well as the ApacheHttpClient4 and then instrument the code to handle cookies properly.

-Russ

From: cowwoc [mailto:cowwoc_at_bbs.darktech.org]
Sent: Wednesday, October 30, 2013 12:25 PM
To: users_at_jersey.java.net<mailto:users_at_jersey.java.net>
Subject: [Jersey] Re: Thread and Performance Considerations of Jersey Client 2.x

Hi John,

On 30/10/2013 1:21 PM, John Zajac wrote:
In a nutshell, what are they?

The 2.x api doc and user guide seem to be silent on the topic. Specifically, I want be able invoke other Restful services from the implementation of another (i.e. from multiple threads) in an efficient manner without unnecessarily regenerating client or targets etc. but of course safely . Googling so far has yielded some advice and comments, mostly for Jersey 1.x, but nothing official for 2.x and not something that is necessarily going to remain true over time for future releases of Jersey.

I have started looking at the source to determine what can be considered thread safe (e.g. maybe the client), or whether it I need to use a pool for 'serial' re-use), and what must be created for each request (e.g. the builder returned by WebTarget.request(String). However, would like some to see what behavior can be depended on across releases.

It would be nice if the jersey user guide could be updated with something along the lines of how jaxb addresses the subject (https://jaxb.java.net/guide/Performance_and_thread_safety.html).

Anyone been down this road already?

    I checked quickly a few months ago and Client, WebTarget looked like they were thread-safe, but the unit tests (JerseyTest class in particular) are not.

    I would prefer thread-safety notes be added to individual class Javadoc or using @ThreadSafe annotations (assume a class is not thread-safe unless it says otherwise) as opposed to pooling the discussion into an external document.

Gili