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) of each other.. but the header I set is the same for both requests. This happens very sporadically... I see no real difference between the requests in wireshark... I just have no clue how this could be happening. Anyone run into this before or have any tips on how to further debug it?

here is the code I use to create the client:

public static HttpClient getAndroidHttpClient(final int timeOut) {
    // set up the schemas
    SchemeRegistry schemeRegistry = new SchemeRegistry();
    schemeRegistry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
    schemeRegistry.register(new Scheme("https", new EasySSLSocketFactory(), 443));

    // set up our params
    HttpParams params = new BasicHttpParams();
    params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, timeOut);
    params.setIntParameter(CoreConnectionPNames.STALE_CONNECTION_CHECK, timeOut);
    params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, timeOut);
    params.setLongParameter(ConnManagerPNames.TIMEOUT, timeOut);
    params.setParameter(ConnManagerPNames.MAX_TOTAL_CONNECTIONS, 1);
    params.setParameter(ConnManagerPNames.MAX_CONNECTIONS_PER_ROUTE, new ConnPerRouteBean(1));
    params.setParameter(HttpProtocolParams.USE_EXPECT_CONTINUE, false);

    HttpProtocolParams.setUserAgent(params, "android-client-v1.0");
    HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
    HttpProtocolParams.setContentCharset(params, "utf8");

    ThreadSafeClientConnManager conman = new ThreadSafeClientConnManager(params, schemeRegistry);

    DefaultHttpClient defaultHttpClient = new DefaultHttpClient(conman, params);

    return defaultHttpClient;
}

Solution 1

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?

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

Comments

[danb]

I thought I ran into a old bug report that said there was a problem somewhere in 4.0 with retrys affecting posts and puts.. but now I can't find it... but Marvins solution did eliminate the second request.. so now I just get "no response" exceptions instead of the dup.

[danb]

Thanks Marvin, your suggestion lead us down the right path.. now at least we know what we're dealing with.

[Suncat2000]

HTTP is not really a delivery protocol at all, it is an application protocol. HTTP is transmitted over TCP, which is the delivery layer. TCP is defined to be a reliable delivery protocol that handles retransmissions and provides the guarantee. I assume that's why @oleg's answer was down-voted.

[ok2c]

@Suncat2000: by non-guaranteed delivery I mean that HTTP protocol makes no provisions for message retransmission in case of a transport failure. Say, the server successfully receives and processes the request but the response is never delivered to the client. HTTP defines some methods to be non-idempotent instead and assumes that both endpoints have a common strategy for dealing with those.