Hi Oleg, thanks again for your answer which somehow confirms my understanding, although I do not really like any of the two options.
> Basically, HTTP provides no mechanism to inform the client > that the server is about to close the connection. Yeah, this should be the big underlying problem. But should this only apply for persistent connections? I see no reason why any in our scenario involved system should abort a request in progress. That’s why I first tried to narrow the problem down in changing von keepAlive (default for performance reasons) to non-keepalive. I expected all requests would be gracefully handled. Any in-flight request should be handled by Synapse before closing any connection. The HWLB itself should detect that the listener is paused on one instance and redirect to another one, also without closing any connection. > 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. Exactly. The only point where I'm currently not sure is who closes the connection at all - Synapse or the HWLB. In my first attemps with activated http nio wire logs on the Synapse side I could not locate the failed requests. Maybe they never arrive their. I guess I have to do some more testing as I still do not fully understand what happens outside http client. Http client itself seems to do a absolutely reasonable job. > * either be prepared to deal with the fact that some requests may never > be received and processed Very bad option for our use cases. ;-) > * 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. Maybe all critical parts really need to be changed to follow this route. Maybe we can try changing the default retry handler in only retrying connection resets independent of whether the request has been fully sent or not. I will have a closer look at the RetryHandler mechanism. Registering a custom one via method params shouldn't be a big deal. > I see no other alternatives. Thanks for your comments which helped to get some confirmation that we have not overlooked some obvious option to easily solve the problem. Regards, Eric
