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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
