On Thu, 2010-06-10 at 20:28 +0200, Hubert, Eric wrote: > Hi Oleg, > > please find attached a client log including wire logs as well as > org.apache.commons.httpclient.HttpMethodDirector on DEBUG level. > > In the log pattern you find a unique request id in brackets just next to the > thread name. This can be used to easily correlated request/response pairs. > > At the beginning you find a request which encounters a Connection reset which > the HttpMethodDirector retries. Request id is > [e8b9b677-2451-477f-aef7-b41d86ccf2bd]. > > The retried request succeeds and receives a response. > > Another request with id [df776149-976e-444b-b7b7-b7148d9847ea] is a working > example (request/response), no retry. > > Request with id [6ce80d68-56f9-4829-829a-ad54410f2bc5] is an example of a > request with no retry and no reply which pops up at the client-side as an > error. > > Reason: > Method retry handler returned false. Automatic recovery will not be attempted > > The problem is although I think I understand what happens on the client-side > I'm still not sure where and how to look for the actual cause of the problem. > > Acording to the current test results it looks like the requests do not reach > the Synapse nodes. So maybe the HWLB closes the connection for some reason? > > Any help how to best proceed with the analysis is greatly appreciated. > > Regards, > Eric >
Eric I think what you are seeing is a general limitation of the HTTP protocol, which was never designed and meant to be used it is being used nowadays. Basically, HTTP provides no mechanism to inform the client that the server is about to close the connection. So, the server shuts down the connection and the client has no idea whether the request has been processed or not. In case of the first request the connection reset occurred before the entire message body had been written out (while flushing the buffer) and therefore the request was assumed safe to retry. In the second case I suppose the entire message was not written out to the underlying connection and therefore the request was assumed unsafe to retry automatically. What is unclear to me is why Synapse dropped both requests prematurely without sending a response of some sort given the fact those connections were non-persistent. Basically when using HTTP as a transport for transactional applications one must choose between one of two models: * either be prepared to deal with the fact that some requests may never be received and processed * or be prepared to deal with the fact that the same request may be received multiple times and the application must be able to recover from such situations. I see no other alternatives. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
