Hi Cory, On Fri, Mar 25, 2011 at 12:30:15PM -0400, Cory Forsyth wrote: > I don't think the number of seconds is significant. I tried it again now, > reloading several times and each time the number of milliseconds in that > SH-- line is different. I think that just indicates how long the > long-polling connection was open when the reload severed it.
OK. > Here's the config: (...) Thank you for this config. I see nothing fancy here. I tried various test patterns with both 1.4.13 and 1.5-dev4 to try to reproduce errors 502, but I could not find a way to get a different behaviour between both of them :-/ There are two possible reasons to get a 502 : - server closes - server returns an invalid response The "SH" log tends to indicate the former, as an invalid response would have had flags "PH" instead (and I have rechecked that they're correctly produced). Still there is something I'm suspecting (which should not differ between both versions). You don't have any option which affects the Connection header. Thus, once the response is received, the connection becomes a tunnel and any data may flow between the client and the server. If the client sends more data than expected to the server and the server closes without reading those data, it may emit a reset. On Linux, it will emit a reset even before the emitted data has been sent or acknowledged, causing the response to be destroyed and to never reach haproxy. By specifying "option http-server-close" in your defaults section, you'll ensure that no excess data will be sent to the server, so it will only get what it expects to receive. If doing so changes something, then you should have a look at the data sent by the client, it is possible that sometimes it is too large. Have you tried to correlate haproxy's logs with the server's logs, to see if the server accepted the request or spotted anything wrong in it ? Regards, Willy
