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