Sergio, This is a very valid point. I believe the entire retry logic should be carefully revised and improved. Clearly, HttpRecoverableException should be more informative by having a status flag or sub-classed into several distinct exception classes.
I just feel that should be done in post 2.0 time frame, together with redirect logic redesign. Feel free to file a bug report, so we do not overlook this problem in the future Oleg On Thu, 2003-03-27 at 18:00, Sergio Berna wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
