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
> <mailto: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]
>> *Gesendet:* Dienstag, 28. Oktober 2014 13:47
>> *An:* users_at_jersey.java.net <mailto: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
>> <mailto: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)
>> <http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#invoke%28java.lang.Class%29>).
>>
>> *Von:*Colin Vipurs [mailto:zodiaczx6_at_gmail.com
>> <mailto:zodiaczx6_at_gmail.com>]
>> *Gesendet:* Dienstag, 28. Oktober 2014 10:44
>> *An:* users_at_jersey.java.net <mailto: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
>> <mailto: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
>> <mailto:rodrigo.uchoa_at_gmail.com>]
>> *Gesendet:* Dienstag, 28. Oktober 2014 00:12
>> *An:* users_at_jersey.java.net <mailto: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.
>>
>
>