Hi Veiko,

On Mon, Feb 04, 2019 at 01:52:28PM +0000, Veiko Kukk wrote:
> I'm sure it happens with all versions we have tried: 1.6, 1.7, 1.9 (did not
> try 1.8, because we have never used it in production and decided to switch
> directly to 1.9), but how could we make sure it's caused by something
> different between versions if we observe very similar results. Since it's
> happening at random, it's hard to judge if there is slight change in one or
> another direction. Logs look same for all versions.

OK, that's what I needed to know.

> Only 'mode tcp' helps to get rid of those errors.
> 
> > Do you know if the responses headers are properly delivered to the
> > client when this happens ? And do they match what you expected ? Maybe
> > the contents are sometimes invalid and the response rejected by haproxy,
> > in which case a 502 would be returned to the client. When this happens,
> > emitting "show errors" on the CLI will report it.
> 
> I don't know, don't know about headers, don't have good tool to capture
> headers for failed connections only. Any suggestions?

In this case it's always the same, tcpdump...

> echo "show errors" |/usr/bin/socat /var/run/haproxy.sock.stats1 stdio
> Total events captured on [04/Feb/2019:13:46:33.167] : 0

Great so it's not an accidental protocol issue that causes this.

> > Could you also check if this happens only/more with keep-alive, close or
> > server-close ?
> 
> I have seen no difference, unfortunately.

OK.

(...)
> >   - option keep-alive
> 
> I assume you meant 'option http-keep-alive' because there is no 'option
> keep-alive'.

Indeed, but you corrected by yourself :-)

> No difference, lot's of incomplete transfers.
> 
> > I'm asking for 2.0-dev because it's where all known bugs are fixed.
> > If none of these settings has any effect, we'll have to look at network
> > traces I'm afraid.
> 
> Would you like to have network traffic dump?

Yes at this point I would really appreciate it (port 80, not 443). Even a
single faulty session, one capture between the client and haproxy and the
equivalent session between haproxy and the server. Please make sure these
do match, it's very important. If your requests/responses contain a unique
ID or a timestamp it should be OK. Alternatively we can add the source pour
into a header, that eases lookups a lot.

Thanks!
Willy

Reply via email to