Nicely done. I feel this is important. Already watching the issue.
On Fri, Nov 7, 2014 at 5:23 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Quoting Effective Java 2nd edition, Item 70: Document thread safety:
>
> "
> How a class behaves when its instances or static methods are subjected to
> concurrent use is an important part of the contract the class makes with
> its clients. If you don’t document this facet of a class’s behavior,
> programmers who use the class will be forced to make assumptions. If
> those assumptions are wrong, the resulting program may perform
> insufficient synchronization (Item 66) or excessive synchronization (Item
> 67). In either case, serious errors can result. [...]
>
> To summarize, every class should clearly document its thread safety properties
> with a carefully worded prose description or a thread safety annotation.
> The synchronized modifier plays no part in this documentation.
> Conditionally thread-safe classes must document which method invocation
> sequences require external synchronization, and which lock to acquire
> when executing these sequences. If you write an unconditionally
> thread-safe class, consider using a private lock object in place of
> synchronized methods. This protects you against synchronization
> interference by clients and subclasses and gives you the flexibility to
> adopt a more sophisticated approach to concurrency control in a later
> release.
> "
>
> Filed https://java.net/jira/browse/JAX_RS_SPEC-490
>
> Gili
>
>
> On 07/11/2014 12:35 PM, Robert DiFalco wrote:
>
> 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.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>