Check out chapter 3 of the Jersey user guide. Specifically:
"Clientinstances 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.
> >>
> >
>