Well, all the problems, the original one that we hit a couple of months ago and the current one are related to one thing: Apache expects some request/response to be read by the downstream haproxy ( and its backends) which refuse to do it due to some error condition and instead sends back a error status like 404, 502, 401 abruptly. Haproxy seem to send a correct response back to Apache as we have seen before, it's the apache that misinterprets it.
Yeah, I definitely need to reproduce this problem in test and see what could be the real cause. I will keep you posted. Thanks Sachin -----Original Message----- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Tuesday, September 20, 2011 10:31 AM To: Sachin Shetty Cc: 'Cassidy, Bryan'; haproxy@formilux.org; 'Amrit Jassal' Subject: Re: Apache translates 500 to 502 from haproxy Hi Sachin, On Mon, Sep 19, 2011 at 01:47:28PM +0530, Sachin Shetty wrote: > Hey Willy, > > So we are now hit by the side effect of this fix i.e. disabling httpclose. > > Two problems: > > 1. Entries in the log are missing, I guess you already warned me about it. > Do you think if we disable keep alive in our Apache fronting haproxy, this > will problem will go away? Yes it will solve this issue at least. BTW, with what I saw in your trace, I really see no reason why http-server-close would not work, because the server advertises a correct content-length so haproxy should wait for both streams to synchronize. Are you sure you had http-server-close in both the frontend and the backend, and that you didn't have any remains of forceclose nor httpclose ? Just in doubt, if you're willing to make a new test, I'm interested in a new trace :-) > 2. Related to one, but an interesting one. > - A request comes to haproxy, as configured after waiting in haproxy > queue for 10 seconds due to backend free connection unavailable, it sends a > 503 back, logged correctly in haproxy and apache > - The client retries, I think with Keep Alive over the same connection > and it sees a 400 status back. Now this request is no where in haproxy logs > so there is no way to see what happened in haproxy and who really dropped > the ball. The connection never made it to the backed cherrypy server since > it logs each request it receives. When you see the 400, is it the standard haproxy response or is it apache ? If it is haproxy, you should see it in its logs, which doesn't seem to be the case. It is possible that the client (or apache ?) continues to send a bit of the remaining POST data before the request and that this confuses the next hop (apache or haproxy). That's just a guess, of course. Cheers, Willy
