hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Berna <sbe...@extendnow.com>
Subject RE: doubt about retry
Date Thu, 27 Mar 2003 17:00:45 GMT
Well, maybe it would be a good suggestion due to the high number of possible
causes for a connection failure which go beyond IOException or HttpException
to add some sort of status to HttpException so that it could be possible to
further get the error cause or at least in which step was the exception
raised (handshake, header, body, etc).

At least i think the connection already closed error which is one of the
most frequent ones while working with a cache pool should have a
preferential order in the list because it is the preferred HttpClient way of
reusing connections.

What do you think?

Sergio.

-----Mensaje original-----
De: Kalnichevski, Oleg [mailto:oleg.kalnichevski@bearingpoint.com]
Enviado el: jueves, 27 de marzo de 2003 16:30
Para: Commons HttpClient Project
Asunto: RE: doubt about retry


Unfortunately, it's not the case
Oleg

-----Original Message-----
From: Sergio Berna [mailto:sberna@extendnow.com]
Sent: Donnerstag, 27. März 2003 16:17
To: Commons HttpClient Project
Subject: RE: doubt about retry


Yes, that was exactly my point.

If its sure that a recoverable exception is only thrown if the body has not
been sent then its good enough for me to guarantee that no data has gone out
of my client. Im not trying to guess if the server has processed something,
just that it has not been sent in any way.

Thx.

-----Mensaje original-----
De: Eric Johnson [mailto:eric@tibco.com]
Enviado el: jueves, 27 de marzo de 2003 15:09
Para: Commons HttpClient Project
Asunto: Re: doubt about retry


Sergio,

As best I can tell, your stated requirement is one that needs to be 
handled at the server.  Consider:

Your client application --> HttpClient --> JRE --> Client OS --> HTTP 
--> Server OS --> HttpServer --> Server application.
and then:
Your client application <-- HttpClient <-- JRE <-- Client OS <-- HTTP 
<-- Server OS <-- HttpServer <-- Server application.

So far as you know, any one of these "layers" could consume your 
request, or the response, and fail to deliver the "response processed" 
message back to your client.  At least, if you're really being paranoid, 
you need to worry about this.

If you want to insure that the server application processes a request at 
most once, then put a unique number into each request, and the server 
should check that that number does not match any earlier requests.  Of 
course, the server would need to reject any request without a unique number.

It might be possible to approximate your need by a change to 
HttpClient.  Right now, it doesn't guarantee when a recoverable 
exception gets thrown.  It could, for example, be thrown before writing 
the body of any request - in which case you would have your iron-clad 
guarantee that server did not get the request.  That could be a 
sufficient level of protection for what you need.  Is it?

-Eric.

Sergio Berna wrote:

>Hello,
>
>
>I have a small question regarding the HttpException that usually happens
>when the connection has been closed previous to re-using it.
>
>In your schema you advise to retry the connection, since a new request
>is
>likely to work. The problem im facing is wheter i can be absolutely sure
>that the first request did not reach the server.
>
>For example imagine im performing some sort of request to a remote
>machine
>through http, this request must be unique and cannot be duplicated. Can
>i be
>fully sure that the first request did not reach the server if i get the
>recoverable error?
>
>Thanks.
>
>Sergio.
>
>  
>


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

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message