I've experienced the same problem with version 1.11. The problem was
with Netty - based client (AHC-1.65), more specifically in
NettyAsyncHttpProvider.remotelyClosed() method. It was possible to
suppress this behavior (which is obviously inappropriate for
non-idempotent methods such as POST) with setting the system property
com.ning.http.client.providers.netty.maxRetry=1.
I'm using both sync and async versions of Jersey client (at this
moment - 1.13) and have not encountered this issue again. The only
situation when I saw something similar with current version of Jersey
was due to my bug when I forgot to call response.finish() in my
Grizzly HttpHandler at the server side - in this case I saw the (GET)
request repeated twice by Jersey client.
Regards,
Igor.
On Wed, Aug 15, 2012 at 2:22 PM, Martynas Jusevičius
<martynas_at_graphity.org> wrote:
> Probably unrelated, but I experienced some double-request behavior
> when I switched to 1.13:
> http://java.net/projects/jersey/lists/users/archive/2012-08/message/27
> Never got a reply though.
>
> On Tue, Aug 14, 2012 at 3:27 AM, <pulkitsinghal_at_gmail.com> wrote:
>> I am using jersey 1.13 and the logs seem to indicate that my client is
>> retrying the same POST request twice!
>>
>> Are the following logs misleading or is there a real problem? Is the
>> request really being sent twice or there is simply dual-logging in the
>> jersey source code somewhere?
>>
>> ### CODE ###
>> WebResource webResource =
>> client.resource("https://pulkitsinghal.dnsdynamic.com:9630/api/invoices
>> /");
>> ClientResponse response =
>> webResource.header("User-Agent", "me.super/1.0")
>> .header("Accept-Encoding", "application/zip")
>> .method("POST", ClientResponse.class,
>> "<createResource></createResource>");
>>
>> ### LOGS ###
>> INFO: 1 * Client out-bound request
>> 1 > POST https://me.super.com:8080/api/invoices/
>> 1 > User-Agent: me.super/1.0
>> 1 > Accept-Encoding: application/zip
>> <createResource></createResource>
>>
>> Aug 13, 2012 7:20:22 PM com.sun.jersey.api.client.filter.LoggingFilter
>> log
>> INFO: 1 * Client out-bound request
>> 1 > POST https://me.super.com:8080/api/invoices/
>> 1 > User-Agent: me.super/1.0
>> 1 > Accept-Encoding: application/zip
>> <createResource></createResource>
>> <createResource></createResource>
>>
>> Aug 13, 2012 7:20:22 PM com.sun.jersey.api.client.filter.LoggingFilter
>> log
>> INFO: 1 * Client in-bound response
>> 1 < 400
>> 1 < Content-Length: 22
>> 1 < Content-Type: text/plain
>> 1 <
>> Malformed Request-Line
>>
>> When I tried the same POST request via JMeter rest client with a post
>> body of <createResource></createResource>, it worked out just fine ...
>> so, what would be some things that I should try out to narrow down or
>> identify the source of the problem better?