RE: doubt about retry
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]
RE: doubt about retry
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]
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]
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]
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]
RE: doubt about retry
Sergio Do not forget that these days people tend to use HTTP protocol for all sorts of things which it has never been envisaged for. HTTP has never been designed to support transactions. HTTP has been designed to support browsing porno-sites (quoting Don Box of Microsoft) There's always a risk of request being successfully processed by the server, but client failing to receive the response. Your application design has to take this problem into consideration. Oleg -Original Message- From: Sergio Berna [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 13:32 To: [EMAIL PROTECTED] Subject: doubt about retry 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]
