Thanks for the responses. In the case of the StaleChecking, we also have an IdleConnectionMonitorThread that will evict connections that are over 20,000ms. We can do this in our environment with relative confidence because we control all the servers and those servers are set to close connections at 30,000ms. That should help to limit the number of 'Connection Resets' we have.
So I guess it comes down to: if I wanted to remove my stalechecking and solely rely on retry handler, what exception would I expect to see if the connection was stale? That way I can account for that in the retry handler. -k -----Original Message----- From: Ken Krugler [mailto:[email protected]] Sent: Wednesday, May 12, 2010 4:18 PM To: HttpClient User Discussion Subject: Re: stale connection 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:[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. -------------------------------------------- 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
