hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Krugler <kkrugler_li...@transpac.com>
Subject Re: stale connection
Date Wed, 12 May 2010 20:17:49 GMT

On May 12, 2010, at 12:28pm, Brooks, Kenneth S wrote:

> If the request made it to the server then we should not be sending  
> another request.
> 1) the server didn't actually process the message..
> 2) the server did process it but didn't return the response  
> correctly..
>
> In either of those cases, while they are frustrating.. we shouldn't  
> be resending.. because we have no mechanism on the server side to  
> identify duplicate messages.
> We might have the client write to an offline store that would  
> reconcile those failed messages later (which we have in some of our  
> applications).
>
>
> Ideally we would *only* retry a request under the following conditions
> 1) failure to make a connection to the server (connect timeout or a  
> stale connection)
> 2) when a request was not fully transmitted to the server
>
>
> So what combination would comply with those requirements?
> StaleChecking [yes/no]

Stale checking only helps reduce the probability of getting an  
IOException - the connection could still go stale in the window of  
time between the check and the request. So it's best to use a retry  
handler.

> DefaultRetryHandler [yes/no]

Unfortunately, as Oleg has tried to explain, for an exception like  
IOException isn't possible to know the difference between "it didn't  
make it to the server" and "the response from the server didn't make  
it back".

So while you can check NoHttpResponseException in the retry handler  
and retry those, you can't do it for the much more common IOException  
case.

-- Ken


> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 12, 2010 2:47 PM
> To: HttpClient User Discussion
> Subject: RE: stale connection
>
> On Tue, 2010-05-11 at 22:04 -0400, Brooks, Kenneth S wrote:
>> We are doing serialization over http..
>> This means that 100% of our calls will *not* be idempotent..
>>
>> I don't see how we can avoid the stale check.
>> Are you saying that NoHttpResponseException is __always__ safe to  
>> retry?
>>
>
> Yes, it is
>
>> I can't take the risk of having a transaction submitted twice..
>
>
> You have that risk _anyways_ unless your application _never_  
> attempts to
> re-execute a failed request.
>
> HTTP is not a transactional transport. In complex network setups It  
> can
> also happen that the client gets an I/O error, even if the message has
> been successfully received and processed by the target server.
>
> You basically have two options: tolerate loss of messages or be  
> prepared
> to handle multiple message submissions.
>
> If your application cannot take action upon the same message twice,  
> the
> only possibility I personally can think of is the use of an unique
> identifier per request message.
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law.  If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED.  Although this transmission and
> any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as
> applicable, for any loss or damage arising in any way from its use.
> If you received this transmission in error, please immediately
> contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.

--------------------------------------------
Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c   w e b   m i n i n g





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


Mime
View raw message