Hi Jarno,
On Wed, Oct 09, 2019 at 02:20:00PM +0300, Jarno Huuskonen wrote:
> > There's no real state machine there, it's roughly "if request was not
> > sent, send it, otherwise try to receive a response; if response is
> > received, then process it and close otherwise wait for response". So
> >
Hi,
Thanks Willy for looking into this !
On Tue, Oct 08, Willy Tarreau wrote:
> On Fri, Oct 04, 2019 at 07:28:15PM +0300, Jarno Huuskonen wrote:
> > I sent pcap/strace offlist.
>
> Thanks, that was very useful.
>
> > (strace -f -o -ttt, tcpdump -n -p -s 16384 -w ... host 127.0.0.1 and
> > port
Hi Jarno,
On Fri, Oct 04, 2019 at 07:28:15PM +0300, Jarno Huuskonen wrote:
> I sent pcap/strace offlist.
Thanks, that was very useful.
> (strace -f -o -ttt, tcpdump -n -p -s 16384 -w ... host 127.0.0.1 and
> port 8080).
>
> I think in packet capture the second health checks causes
>
Hi Willy,
On Fri, Oct 04, Willy Tarreau wrote:
> Hi Jarno,
>
> On Wed, Oct 02, 2019 at 01:08:14PM +0300, Jarno Huuskonen wrote:
> > Hello,
> >
> > I was testing haproxy -> uwsgi(alert.io) and noticed a possible regression
> > with healthchecks(httpchk).
> > With 1.9.9 uwsgi logs:
> >
Hi Jarno,
On Wed, Oct 02, 2019 at 01:08:14PM +0300, Jarno Huuskonen wrote:
> Hello,
>
> I was testing haproxy -> uwsgi(alert.io) and noticed a possible regression
> with healthchecks(httpchk).
> With 1.9.9 uwsgi logs:
> [uwsgi-http key: host.name.fi client_addr: 127.0.0.1 client_port: 45715]
>
5 matches
Mail list logo