ср, 24 июл. 2019 г. в 08:55, Willy Tarreau :
> Hi guys,
> On Tue, Jul 23, 2019 at 08:37:37PM +0200, Jerome Magnin wrote:
> > On Tue, Jul 23, 2019 at 07:09:57PM +0200, Tim Düsterhus wrote:
> > > Jérôme,
> > > Ilya,
> > >
> > > I noticed that FreeBSD CI fails since
> > >
Am 24.07.19 um 05:55 schrieb Willy Tarreau:
> I also noticed the build failure but couldn't find any link to the build
> history to figure when it started to fail. How did you figure that the
> commit above was the first one ?
While I did it as Ilya did by scrolling through GitHub's
On Wed, Jul 24, 2019 at 10:01:33AM +0200, Tim Düsterhus wrote:
> Am 24.07.19 um 05:55 schrieb Willy Tarreau:
> > I also noticed the build failure but couldn't find any link to the build
> > history to figure when it started to fail. How did you figure that the
> > commit above was the first one ?
We are using maps extensively in our architecture to map host headers to
backends. The maps are seeded dynamically with a lua handler to an external
service as requests arrive, there are no pre-seeded values in the map, the
physical map file is empty
On haproxy reload at peak traffic, the
2.0.3 still has the same issue, after 1-3 minutes it goes to using 100% of
it's available cores.
I've created a new strace file. Will send it to you and Willy.
On Tue, Jul 23, 2019 at 8:31 PM Lukas Tribus wrote:
> Hello Elias,
> could you try 2.0.3 please?
I've mentioned that since moving from 1.9.8 to 2.0-branch of haproxy, ereq
counter of frontend tcp-mode sections began to grow. I had zeroes in that
counter before haproxy 2.0, now the number of "error requests" is much
I already tried to get in touch but didn't get any response... not
sure if you receved this? If not interested, please just let me know.
My name is Dennis and I'm a Blog Outreach specialist, I saw your blog
on haproxy.com and decided to get in touch. I think that a lot of my
Exactly this problem:
is still true for frontends, so I can't start a frontend in disabled mode and
later on enable it via socket.
Tested version: 1.8.19 in Debian buster.
I have been looking into load-server-state-from file to prevent 500 errors being
reported after a service reload. Currently we are seeing these, because the new
instance comes up and first wants to see the minimum configured number of health
checks for a backend server to succeed, before it
I am currently running Haproxy 1.6.14-1ppa1~xenial-66af4a1 2018/01/06. There
are many features that were implemented in 1.8, 1.9 and 2.0 that would benefit
my deployments. I tested 2.0.3-1ppa1~xenial last night but unfortunately found
it to be using excessive amounts of CPU and had
We're a local tech company in MN, USA and would love to advertise on
Haproxy.org. Doesn't look like you've got any ads on the home page
currently...is that something we can talk about? We'd just be looking for a
small text mention or a tiny logo-nothing crazy or obtrusive.
Please let me
On Wed, Jul 24, 2019 at 11:01:22AM +0200, Elias Abacioglu wrote:
> Hi Lukas,
> 2.0.3 still has the same issue, after 1-3 minutes it goes to using 100% of
> it's available cores.
> I've created a new strace file. Will send it to you and Willy.
Thanks for testing. I've looked at your
This would explain the 503s
# change a 503 response into a 204(a friendly decline).
errorfile 503 /etc/haproxy/errors/204.http
acl is_disable path_beg /getuid/rogue-ad-exchange
# http-request deny defaults to 403, change it to a 503,
# which is a masked 204 since haproxy
Hello list. I'm trying to send a HTTP 413 to the user based on the
hdr(Content-Length). What I've tried so far:
1. Create a http413 backend only with `errorfile 400` + `http-request
deny_status 400`. In the frontend, configure a `use_backend http413 if
`. This is my current approach but it
On Thu, Jul 25, 2019 at 02:36:49AM +0200, Elias Abacioglu wrote:
> Hi Willy,
> This would explain the 503s
> # change a 503 response into a 204(a friendly decline).
> errorfile 503 /etc/haproxy/errors/204.http
> acl is_disable path_beg /getuid/rogue-ad-exchange
> # http-request
Mail list logo