duplicate requests from HttpClient

Question

I am using HttpClient 4.0.1 on android... I make a POST request with a header set that is the current millis... I see that request hit the server twice within a few millis (5-10

Answer 1

Retry PolicyWe can customized

WITH VOLLEY REQUEST

stringRequest.setRetryPolicy(new DefaultRetryPolicy( 0, DefaultRetryPolicy.DEFAULT_MAX_RETRIES, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT)); volleySingleton.addToRequestQueue(stringRequest);

Answer 2

I cannot speak for HttpClient version shipped with Android, as it is effectively a fork now based on an extremely old pre-BETA snapshot. However, if you are using a stock version of Apache HttpClient 4.x, it DOES NOT automatically retry POST or PUT requests unless configured to do otherwise.

In your particular case I suspect the HTTP message gets retransmitted by the wireless driver due to loss of connectivity or similar networking issue. HTTP is not a guaranteed delivery protocol. HTTP messages can get re-sent by lower level transports. Your application must be prepared to deal with duplicate HTTP messages.

Answer 3

So what appears to be happening here is that your client sends a request, does not get a response in a timely manner, and as a result retries the same request again (as it should). This, in turn, results in multiple POST requests being sent to your server (almost in succession), which your server cannot currently deal with appropriately.

To verify/debug this, try disabling HTTP retries as follows:

defaultHttpClient.setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler
                                             (0, false));

This of course will deal with your duplicate requests issue, but then introduces another more serious issue; namely, it will try once (and only once) and fail. From the information I got from your comments, here are a few ideas you can try:

Please bare with the pseudocode as I don't have all the details of how your client is architected

Handle Multiple POSTS in Succession

• Disable automatic retries (as above)
• Wrap your POST requests in a loop similar to how this is implemented
• Then either sleep between your manual retries or implement your version of exponential backoff

No matter what, your server will need the capability to handle duplicate requests in a reasonable way, this is HTTP afterall. However, you're at least giving it a chance to process the first one before it's bombarded with duplicates.

I recommend that the first step it takes when processing a request is to set some form of a (duplicate) flag. Then if/when it receives a dupe, it continues processing the first request (as usual) and silently ignores the dupes.

So just to summarize, the point of this whole scheme was to give your server a chance to set the dupe flag. After that, it's your server's job to discard (or handle) duplicate requests as needed. Does this all make sense?