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]
