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] DefaultRetryHandler [yes/no] -k -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] 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: [email protected] For additional commands, e-mail: [email protected] 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.
