Le 16/04/2020 à 07:55, Kiran Gavali a écrit :
Hi Christopher,
Thank you or updating the patch. I have seen the "http-check send" directive
you have added in the patch and agree with your point that the syntax must be compatible
with the rework in HTTP checks for H1/H2.
As for the reg-test,
NFP WORKSHOPS
18 Blake Street, York YO1 8QG
Affordable Training Courses for Charities, Schools & Public Sector
Organisations
This email has been sent to haproxy@formilux.org
CLICK TO UNSUBSCRIBE FROM LIST
Alternatively send a blank e-mail to unsubscr...@nfpmail1902.co.uk quoting
On Mon, Apr 27, 2020 at 11:32:15PM +0500, ??? wrote:
> How haproxy.org is managed, some manual update? Can we run git master there?
Yep the upgrade is manual, with an automatic revert to the previous version
in case of sudden death (has happened quite a few times in the past, not
much on
Hi William,
On Mon, Apr 27, 2020 at 08:34:48PM +0200, William Dauchy wrote:
> If this can help, the issue is possibly between dev5 and dev6. We have
> been following quite closely the dev releases, but we had to revert
> from dev6 to dev5 as it produced issues on our side - where it is
>
Hello,
new reg-test requires ALPN which is not available on CentOS 6.
Cheers,
Ilya Shipitcin
From f6edcbacc58ccbfe47f25fccfe6a5743fcae1122 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Mon, 27 Apr 2020 23:35:13 +0500
Subject: [PATCH] CI: cirrus-ci: remove
Hello Willy,
On Mon, Apr 27, 2020 at 7:29 PM Willy Tarreau wrote:
> just a quick note, be careful with -dev6, monitor your FDs from time
> to time. Today it caused an outage on haproxy.org after all FDs were
> in use. Sadly we had skipped a number of -dev in the past, jumping
> from something
How haproxy.org is managed, some manual update? Can we run git master there?
On Mon, Apr 27, 2020, 10:30 PM Willy Tarreau wrote:
> Hi all,
>
> just a quick note, be careful with -dev6, monitor your FDs from time
> to time. Today it caused an outage on haproxy.org after all FDs were
> in use.
Hi all,
just a quick note, be careful with -dev6, monitor your FDs from time
to time. Today it caused an outage on haproxy.org after all FDs were
in use. Sadly we had skipped a number of -dev in the past, jumping
from something between dev2 and dev3 to dev6, so the breakage might
have happened
Hello,
This is my first message here, so: hi everyone :)
And thanks to everyone involved in the Haproxy project !
I wanted to give an idea of a (minor) better default that should be improved:
=> enable by default the "post-41" parameter in *mysql-check*
Today, it's off by default, so Haproxy is
Hi Baptiste,
i'll add the global maxconn, but according to stats link we never go over
40 ...
We do use keepalive, but i'll need to adjust our logs to see if this is the
first or some other request within the keepalive session.
We seem to have managed to fix the problem. By setting "no option
On Mon, Apr 27, 2020 at 10:14 PM Baptiste wrote:
>
>
> On Mon, Apr 27, 2020 at 3:05 AM Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>> Hi,
>>
>> On Mon, Apr 20, 2020 at 10:25 PM Igor Cicimov <
>> ig...@encompasscorporation.com> wrote:
>>
>>> Hi,
>>>
>>> I have the following template
On Mon, Apr 27, 2020 at 3:05 AM Igor Cicimov
wrote:
> Hi,
>
> On Mon, Apr 20, 2020 at 10:25 PM Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>> Hi,
>>
>> I have the following template in a server backend:
>>
>> server-template tomcats 10 _tomcat._tcp.service.consul resolvers consul
Hi,
first, you need to set a global maxconn to 3000, otherwise it may be
limited by your system. In any case, the frontend maxconn will never be
reachable with your current config.
do you know if that happens on keep alive requests or if this happens on
the first request of the connection? Do you
13 matches
Mail list logo
