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