Hi,
I read that. From that I gather that I should create a static single instance of Client, shared across all threads, all classes that would use it to create resources.. is that correct?
Where I am not sure of is the WebResource. In my case I may end up with 100's of different urls/paths to send requests to. For each I'd have to create a new WebResource instance I believe. However, if after a given url/path Webresource is created I may need it again to send more requests to, I assume from this doc that I should keep the instance around to reuse it and that it too is thread safe. So for any reason if various threads (say different users) are sending something to the same url/path, I'd use the same one WebResource instance and calling methods on it from different threads is safe?
Thanks
--- On Mon, 7/11/11, Ryan Stewart <rds6235_at_gmail.com> wrote:
From: Ryan Stewart <rds6235_at_gmail.com>
Subject: [Jersey] Re: What is the right way to handle threading with jersey client
To: users_at_jersey.java.net
Date: Monday, July 11, 2011, 10:22 AM
Check out chapter 3 of the Jersey user guide. Specifically: "Client instances are expensive resources. It is recommended a configured
instance is reused for the creation of Web resources. The creation of Web resources, the building
of requests and receiving of responses are guaranteed to be thread safe. Thus a
Client
instance and
WebResource instances may be shared between multiple threads."
http://jersey.java.net/nonav/documentation/latest/user-guide.html#client-api
On Mon, Jul 11, 2011 at 10:43 AM, Andjarnic <andjarnic_at_yahoo.com> wrote:
Hi all,
I am using jersey client between servers to send objects from one server to another. The first server is a web server and is likely going to have hundreds of request come in at the same time all which will use the code tha uses jersey client to send objects to various other servers. I would like to know how best to use jersey client with threading to avoid wasting object creation of Client, WebResource and possibly ClientResponse (and anything else).
Can i create a single static instance of Client and one WebResource for each url i send objects to and reuse those in multiple threads? Do i need to create a new WebResource for each thread even if the same url is used?
Thank you
Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
>Hello Peter,
>
>thanks for evaluation!
>
>We had somehow similar issue (actually very similar, it just caused
>different kind of problems) and yeah, it is about not reading response,
>respective not closing opened input stream. You can achieve it by doing:
>
> Client c = Client.create();
> WebResource wr = c.resource("http://host/path");
> ClientResponse cr = wr.get(ClientResponse.class);
> cr.close();
>
> // and when you actually do want to get entity, just do
>following (close() is called automatically this way)
>
> SomeClass sc = cr.getEntity(SomeClass.class);
>
>And to answer.. is this a bug withing jersey client? I don't think so -
>we can't really know/predict whether you are going to read the response
>entity or not and HttpURLConnection implementation in jdk relies on
>closing gathered InputStream.. which (again) makes sense, because it
>cannot be sure whether you are going to use it or not.
>
>Please let me know if this solved your problem and/or if you have some
>further comments or observations.
>
>Thanks,
>Pavel
>
>
>On 7/11/11 4:49 PM, peterjca wrote:
>> I'm responding to my own post here because I found the cause of the extra
>> requests.
>>
>> I plugged in the ApacheHttpClient to see if that would make any difference.
>> Whilst googling about ApacheHttpClient I came across various issues people
>> were having with it. One in particular was due to code throwing away a
>> response i.e. not reading a response, and causing hanging.
>>
>> Indeed, I was not reading the response of the RatingResource because I
>> wasn't particularly interested in it for my tests, and experienced hanging.
>> Once I read it the problem went away.
>>
>> I'll now redo my tests with the standard Jersey client.
>>
>> So isn't this a bug in Jersey? If you don't read all responses then Jersey
>> goes funny and you end up getting extra requests for some reason.
>>
>>
>> --
>> View this message in context: http://jersey.576304.n2.nabble.com/Is-Jersey-Jersey-client-duplicating-requests-tp6570645p6571176.html
>> Sent from the Jersey mailing list archive at Nabble.com.
>>
>