hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Glück (JIRA) <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
Date Wed, 04 Nov 2009 13:23:32 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773475#action_12773475
] 

Ortwin Glück commented on HTTPCLIENT-886:
-----------------------------------------

> In our case, this is very dangerous because the request has already been sent and is
being processed by the back-end server. 

If a repeated request is "very dangerous" you'd better implementing detection for duplicate
requests in your application! Use challenge/reponse tokens, sequence numbers, timestamps or
other means to detect repeated requests. The behaviour of HttpClient is not the only source
for repeated requests. Messaging over any unreliable medium (like a network) ALWAYS has to
make the choice between either loosing some messages, or accepting and dealing with duplicates.
This is a fundamental theorem. It's the reason for why there is UDP and TCP and their different
guarantees.

If the client doesn't get a response it can never know whether the request didn't reach the
server or the response just didn't reach the client. By not retrying the request, the client
risks that the request never reached the destination. It HAS TO retry the request until it
gets a response. This algorithm is called Idle-RQ and is used for TCP for instance.

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-886
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>    Affects Versions: 3.1 Final
>            Reporter: Sylvain Laurent
>            Priority: Critical
>             Fix For: 3.1.1
>
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server,
and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled
by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking
for a retry. In our case, this is very dangerous because the request has already been sent
and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent()
shoud be done :
>         if (exception instanceof NoHttpResponseException && !method.isRequestSent())
{
>             // Retry if the server dropped connection on us AND the request was not sent
>             return true;
>         }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message