users@jersey.java.net

[Jersey] Re: Pool for javax.ws.rs.client.Client objects?

From: Robert DiFalco <robert.difalco_at_gmail.com>
Date: Fri, 7 Nov 2014 09:35:28 -0800

My vote would be for NOT being thread safe.

On Fri, Nov 7, 2014 at 9:13 AM, Marek Potociar <marek.potociar_at_oracle.com>
wrote:

> It’s actually JAX-RS spec that should clarify this. Please file a new
> issue <https://java.net/jira/browse/JAX_RS_SPEC> if you care.
>
> Cheers,
> Marek
>
> On 28 Oct 2014, at 15:04, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
> I'm saying that the Jersey team needs to document thread-safety if it
> exist (and yes, I believe this code really is thread-safe).
>
> Gili
>
> On 28/10/2014 9:53 AM, Rodrigo Uchôa wrote:
>
> So we can make no assumptions about the thread-safety of the Client class?
> Back to square one then. Pooling is the right approach.
>
> On Tue, Oct 28, 2014 at 11:44 AM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> The exact opposite is true.
>>
>> The Javadoc/specification is a contract. Anything that is not explicitly
>> listed is an implementation detail that may change at any time.
>>
>> Gili
>>
>>
>> On 28/10/2014 8:49 AM, Markus Karg wrote:
>>
>> Don’t understand your critics. Isn’t it typical in all JavaDocs to only
>> warn about MISSING thread-safety?
>>
>>
>> *Von:* Rodrigo Uchôa [mailto:rodrigo.uchoa_at_gmail.com
>> <rodrigo.uchoa_at_gmail.com>]
>> *Gesendet:* Dienstag, 28. Oktober 2014 13:47
>> *An:* users_at_jersey.java.net
>> *Betreff:* [Jersey] Re: Pool for javax.ws.rs.client.Client objects?
>>
>>
>> I just find it really weird that if Client objects should be implemented
>> in a thread-safe way, this is not explicit in the javadocs. :) But it does
>> make things a lot easier if it is.
>>
>>
>> On Tue, Oct 28, 2014 at 8:31 AM, Markus Karg <karg_at_quipsy.de> wrote:
>>
>> FYI: Reuse of objects can also be done on the level of targets and
>> invocation templates, a.k.a. Invocation class: You can invoke it several
>> times using different values (see
>>
>> http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property(java.lang.String,
>> java.lang.Object)
>> <http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property%28java.lang.String,%20java.lang.Object%29>
>> and
>> http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#invoke(java.lang.Class)
>> ).
>>
>>
>> *Von:* Colin Vipurs [mailto:zodiaczx6_at_gmail.com]
>> *Gesendet:* Dienstag, 28. Oktober 2014 10:44
>> *An:* users_at_jersey.java.net
>> *Betreff:* [Jersey] Re: Pool for javax.ws.rs.client.Client objects?
>>
>>
>> This is exactly what we do across all our services. You should notice
>> quite the performance improvement switching to this as well
>>
>>
>> On Tue, Oct 28, 2014 at 9:10 AM, Markus Karg <karg_at_quipsy.de> wrote:
>>
>> Did you find any official documentation which says that you must not use
>> one single client concurrently by different threads? If not, why not just
>> using a single instance?
>>
>>
>> *Von:* Rodrigo Uchôa [mailto:rodrigo.uchoa_at_gmail.com]
>> *Gesendet:* Dienstag, 28. Oktober 2014 00:12
>> *An:* users_at_jersey.java.net
>> *Betreff:* [Jersey] Pool for javax.ws.rs.client.Client objects?
>>
>>
>> Hi guys!
>>
>>
>> I have a client web application that uses the Client API to make REST
>> calls to a REST business layer.
>>
>>
>> The javax.ws.rs.client.Client docs clearly states that Client objects are
>> expensive to create and dispose, and only a small number of them should be
>> created, which makes me think they should be pooled somehow.
>>
>>
>> Our initial thought was to instantiate and then close every Client object
>> we use, making code like this:
>>
>>
>> public void doSomething() {
>>
>> Client client = ClientBuilder.newClient();
>>
>> //do a bunch of stuff here
>>
>> client.close();
>>
>> }
>>
>>
>> Every method that needs to invoke REST services are coded like the
>> example above. That means every time a client web request comes in, a new
>> Client object is created and then closed. The exact opposite of what the
>> docs advises us to do.
>>
>>
>> How should we implement a pool of Client objects in this scenario? Is
>> there a common solution?
>>
>>
>> Regards,
>>
>> Rodrigo Uchoa.
>>
>>
>>
>>
>>
>> --
>> Maybe she awoke to see the roommate's boyfriend swinging from the
>> chandelier wearing a boar's head.
>>
>> Something which you, I, and everyone else would call "Tuesday", of
>> course.
>>
>>
>>
>>
>
>
>