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