ad Request + Response bytes there, but I think it's less useful.
> > So I added the counters, but do not expose them for requests yet, as I'm
> > unsure where to do that exactly, but that can easily be addressed with a
> > separate commit.
>
> Yes we can
Hi,
On Tue, Apr 04, 2023 at 09:45:24PM +0200, Willy Tarreau wrote:
> Hi Olivier,
>
> On Tue, Apr 04, 2023 at 12:29:15AM +0200, Olivier Houchard wrote:
> > Hi,
> >
> > The attached patchset is a first attempt at adding the possibility to
> > compress requests, a
requests, "response" if you want to compress
responses or "both", if you want to compress both.
The default is to compress responses only.
Any comment is more than welcome.
Thanks!
Olivier
>From 6c3e62baa888359521091387ce6ac8376a001259 Mon Sep 17 00:00:00 2001
From: Olivi
ger
happens.
Another possibility of h1_release() been called while still in the
idle tree is if h1_wake() gets called, but the only way I see that
happening is from mmux_stopping_process(), whatever that is, so that's
unlikely to be the problem in this case.
Anyway, I suggest doing something along
Hi Marc,
On Mon, Jan 23, 2023 at 12:13:13AM -0600, Marc West wrote:
> Hi,
>
> We have been running HAProxy on OpenBSD for serveral years (currently
> OpenBSD 7.2 / HAProxy 2.6.7) and everything has been working perfect
> until a recent event of higher than normal traffic. It was an unexpected
> f
Hi Bart,
On Thu, Nov 18, 2021 at 08:06:55PM +0100, Bart van der Schans wrote:
> Here is the patch:
>
> Fix "block" ACL by reverting accidental removal of code in
> 8ab2a364a8c8adf0965e74a41a2ff3cebd43e7a9
> ---
> diff --git a/src/cfgparse.c b/src/cfgparse.c
> index 857321e1..78f0ed76 100644
> ---
On Thu, Nov 18, 2021 at 05:59:24PM +0100, Bart van der Schans wrote:
> A bit more digging:
>
> It looks like this commit broke it:
> http://git.haproxy.org/?p=haproxy-2.0.git;a=commitdiff;h=8ab2a364a8c8adf0965e74a41a2ff3cebd43e7a9
>
> Re-adding the following block on line 2826 in cfgparse.c in 2.
On Wed, Sep 09, 2020 at 05:35:28PM +0200, Willy Tarreau wrote:
> On Wed, Sep 09, 2020 at 04:57:58PM +0200, William Dauchy wrote:
> > > I think it's not easy to reproduce these tests, you need a high enough
> > > latency between haproxy and the client so that the handshake is not
> > > already compl
Hi Dmitry,
On Sat, Jun 20, 2020 at 03:30:55PM +0300, Dmitry Sivachenko wrote:
> Hello!
>
> I am trying to compile haproxy-2.2-dev10 on FreeBSD-12/i386 (i386 is
> important here) with clang version 9.0.1.
>
> I get the following linker error:
>
> LD haproxy
> ld: error: undefined symbol:
Hi William,
On Mon, May 04, 2020 at 02:08:54PM +0200, William Dauchy wrote:
> On Mon, May 04, 2020 at 01:56:10PM +0200, William Dauchy wrote:
> > Sorry for this one, I originally did update the server.h file, but I
> > don't know why I forgot to add it in my patch submission :/
> > then I saw you
On Sat, May 02, 2020 at 10:23:05PM +0200, William Dauchy wrote:
> On Sat, May 02, 2020 at 10:17:01PM +0200, Olivier Houchard wrote:
> > If that's the only change you have for a v2, don't bother, I already
> > integrated it in what I plan to push :)
>
> ok, thanks
On Sat, May 02, 2020 at 10:14:15PM +0200, William Dauchy wrote:
> On Sat, May 02, 2020 at 09:52:36PM +0200, William Dauchy wrote:
> > +void srv_cleanup_connections(struct server *srv)
> > +{
> > + struct connection *conn;
> > + int did_remove;
> > + int i;
> > + int j;
> > +
> > + HA_SPIN
Hi William,
On Sat, May 02, 2020 at 09:52:35PM +0200, William Dauchy wrote:
> Hello Olivier,
>
> The following patch is an attempt to fix a change of behavior we encounter
> following commit:
>
> 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are
> killed")
> being the ori
On Fri, Mar 27, 2020 at 04:32:21PM +0100, Christian Ruppert wrote:
> On 2020-03-27 16:27, Olivier Houchard wrote:
> > On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
> >> During the reload I just found something in the daemon log:
> >> Mar 27 13
On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
> During the reload I just found something in the daemon log:
> Mar 27 13:37:54 somelb haproxy[20799]: [ALERT] 086/133748 (20799) :
> Starting proxy someotherlistener: cannot bind socket [0.0.0.0:18540]
> Mar 27 13:37:54 somelb hap
Hi Christian,
On Fri, Mar 27, 2020 at 02:37:41PM +0100, Christian Ruppert wrote:
> Hi list,
>
> we have some weird issues now, the second time, that *some* SSL sockets
> seem to be broken as well as stats sockets.
> HTTP seems to work fine, still, SSL ones are broken however. It happened
> at l
Hi Willy,
On Wed, Mar 25, 2020 at 02:03:56PM +0100, Willy Tarreau wrote:
> On Wed, Mar 25, 2020 at 12:40:33PM +0100, Olivier Houchard wrote:
> > I think I figured it out, and commit
> > 69664419d209d2f64dbcd90f991e7ec2efff2ee2
> > should fix it, at least now I can d
Hi Pieter,
On Wed, Mar 25, 2020 at 01:42:14AM +0100, Olivier Houchard wrote:
> Hi Pieter,
>
> On Wed, Mar 25, 2020 at 01:14:46AM +0100, PiBa-NL wrote:
> > Hi List, Willy,
> >
> > Today i thought lets give v2.2-dev5 a try for my production environment ;).
> >
Hi Pieter,
On Wed, Mar 25, 2020 at 01:14:46AM +0100, PiBa-NL wrote:
> Hi List, Willy,
>
> Today i thought lets give v2.2-dev5 a try for my production environment ;).
> Soon it turned out to cause SVN-Checkout to stall/disconnect for a
> repository we run locally in a Collab-SVN server.
>
> I tra
Hi,
On Mon, Mar 09, 2020 at 10:33:55AM +0200, Emilio Fernandes wrote:
> Hello HAProxy team,
>
> At https://www.haproxy.org/#plat I see that ARM architecture is supported
> for Linux with newer kernel.
> To avoid confusion could you please add next to it whether it is only 32
> bit, 64 bit or both
Hi guys,
On Tue, Jan 14, 2020 at 09:45:34PM +0100, Willy Tarreau wrote:
> Hi guys,
>
> On Tue, Jan 14, 2020 at 08:02:51PM +0100, PiBa-NL wrote:
> > Below a part of the output that the test generates for me. The first curl
> > request seems to succeed, but the second one runs into a timeout..
> >
Hi David,
On Tue, Sep 17, 2019 at 04:58:28PM -0500, David Pirotte wrote:
> Hi all,
>
> Is there a way to multiplex frontend HTTP/2 (GRPC) connections onto a shared
> pool of backend HTTP/2 connections?
>
> My testing shows that one frontend connection with multiple concurrent
> requests will r
On Wed, Aug 07, 2019 at 03:09:26PM +0200, Emmanuel Hocdet wrote:
> Hi,
>
> Two patches to fix (and simplify) 0-RTT for BoringSSL.
> If you can consider them.
>
> ++
> Manu
>
Applied, thanks !
Olivier
Hi Fred,
On Thu, Jul 04, 2019 at 02:37:55PM +0200, Frederic Lecaille wrote:
> On 7/4/19 1:36 PM, Olivier Houchard wrote:
> > Hi William,
> >
> > On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:
> > > Hello,
> > >
> > > On haproxy
Hi William,
On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:
> Hello,
>
> On haproxy v2.0.x, while using tfo option in default-server:
> default-server inter 5s fastinter 1s fall 3 slowstart 20s observe layer7
> error-limit 5 on-error fail-check pool-purge-delay 10s tfo
> we are
Hi Maksim,
On Fri, Jun 28, 2019 at 04:09:48PM +0300, Максим Куприянов wrote:
> Hi!
>
> I found out that in some situations under high rate of incoming connections
> haproxy=2.0.1 starts leaking sockets. It looks like haproxy doesn't close
> connections to its backends after request is finished (F
Hi Luke,
On Fri, Jun 28, 2019 at 07:05:32AM +0200, Luke Seelenbinder wrote:
> Hello all,
>
> I've found a segfault in v2.0.1. I believe the issue is a no-ssl directive on
> a server line after seeing check ssl on default-server in defaults. Here's
> the snips of my config. I haven't been able t
Hi Maksim,
On Tue, Jun 25, 2019 at 01:29:24PM +0300, Максим Куприянов wrote:
> Hi!
>
> Got SIGSEGV in ssl_subscribe function. Happens multiple times per day.
> Haproxy was built from trunk with commits upto:
> http://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=9eae8935663bc0b27c23018e8cc24ae9a3
Hi Igor,
On Sun, Jun 23, 2019 at 08:42:46PM +0800, Igor Pav wrote:
> Hi Olivier,
>
> The `retry-on 0rtt-rejected` will only work in tcp mode, is that
> possible to let it work in http mode too?
>
It should work with HTTP too. What may happen is you're using "alpn" on
the server line, and thus w
Hi Igor,
On Sat, Jun 15, 2019 at 07:19:24PM +0800, Igor Pav wrote:
> Hi Olivier,
>
> Still suffering from 2.0-dev7-b6563f-41 :(
>
I can't seem to reproduce it.
I found a potential issue, and 965e84e2df7ba448d887bd5e9e03d76b206d3eee may
help.
If it does not, how do you reproduce it ? Which clien
Hi Igor,
On Sat, Jun 15, 2019 at 03:00:23AM +0800, Igor Pav wrote:
> Hello, dev
>
> The commit of ea8dd949e4ab7ddd94afdbf0e96087c883192217 seems to break
> the allow-0rtt in server line, a connection will take very very long
> to complete. Remove allow-0rtt it turns normal.
>
> conf like:
>
> l
On Thu, Jun 06, 2019 at 08:33:26PM +0200, PiBa-NL wrote:
> Hi Olivier,
>
> Op 6-6-2019 om 18:20 schreef Olivier Houchard:
> > Hi Pieter,
> >
> > On Wed, Jun 05, 2019 at 09:00:22PM +0200, PiBa-NL wrote:
> > > Hi Olivier,
> > >
> > > It seems
Hi Pieter,
On Wed, Jun 05, 2019 at 09:00:22PM +0200, PiBa-NL wrote:
> Hi Olivier,
>
> It seems this commit ea8dd94 broke something for my FreeBSD11 system.
> Before that commit (almost) all vtest's succeed. After it several cause
> core-dumps. (and keep doing that including the current HEAD: 03a
Hi William,
On Wed, May 15, 2019 at 01:10:37PM +0200, William Dauchy wrote:
> Hello Olivier,
>
> In another subject related to 0rtt was wondering why it was not
> available in ssl-default-bind-options?
>
We usually only add options in ssl-default-bind-options that can later be
overriden on a pe
Hi Maciej,
On Thu, May 09, 2019 at 07:25:54PM +0200, Maciej Zdeb wrote:
> Hi again,
>
> I have bad news, HAProxy 1.9.7-35b44da still looping :/
>
> gdb session:
> h2_process_mux (h2c=0x1432420) at src/mux_h2.c:2609
> 2609list_for_each_entry_safe(h2s, h2s_back, &h2c->send_list, list) {
>
Hi Maciej,
On Thu, May 09, 2019 at 02:19:26PM +0200, Maciej Zdeb wrote:
> Hi Willy,
>
> I've built 1.9 from head, unfortunately something is wrong, right now I've
> got segfault:
>
> Core was generated by `/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p
> /var/run/haproxy.pid -D -sf 75'.
> Prog
On Wed, May 08, 2019 at 02:30:07PM +0200, Willy Tarreau wrote:
> On Wed, May 08, 2019 at 01:56:05PM +0200, Olivier Houchard wrote:
> > > > One of processes stuck in infinite loop, admin socket is not responsive
> > > > so
> > >
Hi,
On Wed, May 08, 2019 at 07:11:27AM +0200, Willy Tarreau wrote:
> Hi Maciej,
>
> On Tue, May 07, 2019 at 07:08:47PM +0200, Maciej Zdeb wrote:
> > Hi,
> >
> > I've got another bug with 100% CPU on HAProxy process, it is built from
> > HEAD of 1.9 branch.
> >
> > One of processes stuck in infi
Hi Ilya,
On Mon, May 06, 2019 at 12:54:56AM +0500, Илья Шипицин wrote:
> hello,
>
> when I first sent LibreSSL patches (it was 27th April 2019), reg-tests were
> ok.
> I suspect recent 0RTT patches could break LibreSSL things
>
> can someone have a look ?
>
> https://travis-ci.org/chipitsine/ha
Hi Igor,
On Mon, May 06, 2019 at 12:26:33AM +0800, Igor Pav wrote:
> Hi, Olivier, thanks for the effort. So can we force the server always
> to carry data to remote via 0RTT like below scenario(to protect
> http2http in unsecured env)?
>
> listen http -- server default x.x ssl allow-0rtt (SSL
Hi Igor,
On Fri, May 03, 2019 at 05:21:50PM +0800, Igor Pav wrote:
> Just tested with openssl 1.1.1b and haproxy 1.9.7, it appears no
> success, you are right :)
>
Indeed :)
I just pushed commit 010941f87605e8219d25becdbc652350a687d6a2 to master, that
let me do 0RTT both as server and as client.
Hi Igor,
On Thu, May 02, 2019 at 08:39:58PM +0800, Igor Pav wrote:
> Hello, can we use TLS zero RTT in server-side now? Just want to reduce
> more latency when using SSL talk to the backend servers(also running
> haproxy).
>
> Thanks in advance. Regards
>
It should work if you add "allow-0rtt"
Hi Ilya,
On Tue, Apr 30, 2019 at 09:23:21PM +0500, ?? wrote:
> Hello,
>
> typo was found by cppcheck
>
> thank!
> Ilya Shipitsin
> From 62c6b78843e9c1b6f829872a54175f68332a2859 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin
> Date: Tue, 30 Apr 2019 21:21:28 +0500
> Subjec
Hi Maciej,
On Tue, Apr 30, 2019 at 08:43:07AM +0200, Maciej Zdeb wrote:
> Filtered results from show fd for that particular virtual server:
>
> 10 : st=0x22(R:pRa W:pRa) ev=0x01(heopI) [lc] cnext=-3 cprev=-2 tmask=0x1
> umask=0x0 owner=0x53a5690 iocb=0x59d689(conn_fd_handler) back=0
> cflg=0x8024
Hi,
On Fri, Apr 12, 2019 at 08:37:10AM +0200, Maciej Zdeb wrote:
> Hi Richard,
>
> Those patches from Olivier (in streams) are related to my report from
> thread "[1.9.6] One of haproxy processes using 100% CPU", but as it turned
> out it wasn't a single bug and issue is not entirely fixed yet.
>
Hi Maciej,
On Fri, Apr 05, 2019 at 01:33:29PM +0200, Maciej Zdeb wrote:
> I think I found something, please look at the session 0x2110edc0 and
> "calls", it never ends:
>
> socat /run/haproxy/haproxy2.sock - <<< "show sess all"
> 0x2110edc0: [05/Apr/2019:12:03:32.141927] id=14505 proto=tcpv4
> so
Hi Maksim,
On Thu, Mar 28, 2019 at 04:36:16PM +0300, ?? wrote:
> Hi!
>
> We accidentally got a spike of client requests to our site and under that
> heavy load to ssl-protected backends haproxy=1.9.5 had fallen down :(
>
I think I understand how it may have happened
Hi David,
On Wed, Mar 27, 2019 at 04:13:28PM +, David CARLIER wrote:
> Hi Here a little patch proposal.
>
> Kind regards.
Sounds good ! I pushed it.
Thanks a lot !
Olivier
Hi Richard,
On Wed, Feb 20, 2019 at 11:58:42PM +, Richard Russo wrote:
> While continuing to test this, I ended up with a crash in
> listener.c:listener_accept on a closed/closing listen socket where
> fdtab[fd].owner is NULL by the time the thread gets there. This is possible
> because the
Hi Patrick,
On Thu, Feb 14, 2019 at 09:12:18AM -0500, Patrick Hemmer wrote:
>
>
> On 2019/2/14 08:20, Frederic Lecaille wrote:
> > On 2/14/19 1:32 PM, Frederic Lecaille wrote:
> >> On 2/13/19 7:30 PM, Patrick Hemmer wrote:
> >>>
> >>>
> >&g
clude/common/initcall.h:78:2: note: expanded from macro
> >> '_DECLARE_INITCALL'
> >> __DECLARE_INITCALL(__VA_ARGS__)
> >> ^
> >> include/common/initcall.h:65:42: note: expanded from macro
> >> '__DECLARE_INITCALL
eb48 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Thu, 17 Jan 2019 15:59:13 +0100
Subject: [PATCH] BUG/MEDIUM: servers: Make assign_tproxy_address work when
ALPN is set.
If an ALPN is set on the server line, then when we reach assign_tproxy_address,
the stream_interface's endpoin
t; If I disable h2 on the backend, it works correctly. If I disable the source
> in defaults, it works correctly. I've attached the backtrace below.
>
> Best,
> Luke
>
I think I understand what's going on.
Does the attached patch fix it for you ?
Thanks a lot !
Olivier
(), so
that set_server_check_status() is call, and the check's status and result
may be updated. Not sure it is really needed, but I'd rather not offend
the Check Gods.
The attached patches are updated to od just that.
Regards,
Olivier
>From 7e7b41cac480029c5fd93338dd86a875fee0b5a
On Fri, Jan 11, 2019 at 06:53:11PM +0100, Olivier Houchard wrote:
> Hi,
>
> On Fri, Jan 11, 2019 at 10:36:04AM +0100, Johan Hendriks wrote:
> > Thanks all.
> > No rush on my side as it is a test machine, at least we do know when a
> > backend server fails.
> > W
Regards,
> > PiBa-NL (Pieter)
>
Ok so erm, I'd be lying if I claimed I enjoy working on the check code, or
that I understand it fully. However, after talking with Willy and Christopher,
I think I may have comed with an acceptable solution, and the attached patch
should fix it (at least
Hi Willy,
On Tue, Jan 08, 2019 at 03:44:07PM +0100, Willy Tarreau wrote:
> On Tue, Jan 08, 2019 at 03:27:58PM +0100, Olivier Houchard wrote:
> > On Tue, Jan 08, 2019 at 03:00:32PM +0100, Janusz Dziemidowicz wrote:
> > > pt., 4 sty 2019 o 11:59 Olivier Houchard
> > >
Hi,
On Wed, Jan 09, 2019 at 01:44:08AM -0500, cripy wrote:
> Hi,
>
> I found a segfault when using server-template within 1.9.x and 2.0-dev.
> This seems to be related to "http-reuse" as when I set to "never" it does
> not crash anymore.
>
> It appears that idle_orphan_conns is not being proper
On Tue, Jan 08, 2019 at 03:00:32PM +0100, Janusz Dziemidowicz wrote:
> pt., 4 sty 2019 o 11:59 Olivier Houchard napisa??(a):
> > I understand the concern.
> > I checked and both nghttp2 and nginx disable the replay protection. The idea
> > is you're supposed to allow e
Hi Janusz,
On Fri, Jan 04, 2019 at 10:53:51AM +0100, Janusz Dziemidowicz wrote:
> czw., 3 sty 2019 o 17:52 Olivier Houchard napisa??(a):
> > Ah I think I figured it out.
> > OpenSSL added anti-replay protection when using early data, and it messes up
> > with the session h
Hi Janusz,
On Thu, Jan 03, 2019 at 11:49:35AM +0100, Janusz Dziemidowicz wrote:
> ??r., 2 sty 2019 o 19:04 Olivier Houchard napisa??(a):
> > You're right indeed. 0RTT was added with a development version of OpenSSL
> > 1.1.1,
> > which had a default value for max early
ou ?
Thanks !
Olivier
>From cdb864da7cebb97800aef2e114bae6f0d0f96814 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Wed, 2 Jan 2019 18:46:41 +0100
Subject: [PATCH] MEDIUM: ssl: Call SSL_CTX_set_max_early_data() to enable
0RTT.
When we want to enable early data on a listener, explicit
> cheers,
Ooops you're right indeed. The attached patch should fix it.
Thanks a lot for reporting !
Regards,
Olivier
>From 2276c53dac820d0079525730e9bd7abfd3ea408c Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Mon, 24 Dec 2018 13:32:13 +0100
Subject: [PATCH] BUG/MEDIUM: servers: Don't try to
On Thu, Nov 15, 2018 at 02:26:59PM +0100, Willy Tarreau wrote:
> On Thu, Nov 15, 2018 at 11:58:36AM +0100, Olivier Houchard wrote:
> > Willy, can you push the attached patch ?
>
> Applied, thanks. I've just slightly edited it to put parenthesis around
> "i" below
On Thu, Nov 15, 2018 at 09:48:20AM +, Paul Martin wrote:
> On Wed, Nov 14, 2018 at 06:05:00PM +0100, Olivier Houchard wrote:
>
> > Oops, you're right indeed.
> > I'm not sure I'm a big fan of special-casing STD_T_UINT. For example,
> > STD_T_FRQP is pro
example,
STD_T_FRQP is probably 12bytes too, so it'd be a problem.
Can you test the (untested, but hopefully right) patch attached ?
Thanks a lot !
Olivier
>From 50027352049d64b874e1116758400580541ea49f Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Wed, 14 Nov 2018 17:54:36 +0100
On Tue, Oct 16, 2018 at 05:02:30PM +0200, Willy Tarreau wrote:
> On Tue, Oct 16, 2018 at 04:11:20PM +0200, Willy Tarreau wrote:
> > Could you please apply the attached patch ? I'm going to merge it into 1.9
> > and we'll backport it to 1.8 later.
>
> And please add the attached one as well, which
Hi Soji,
On Mon, Oct 15, 2018 at 11:10:09PM +0530, Soji Antony wrote:
> Hi Olivier,
>
> Many thanks for your reply.
> Please find the gdb output given below.
>
> # gdb /usr/sbin/haproxy core.dump3.13871
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
> Copyright (C) 2014 Free Software Foundation
te_setsize+0x32/0x40
> > Oct 10 19:16:28 int16 kernel: [193201.152509] []
> > xfs_setattr_size+0x168/0x3d0 [xfs]
> > Oct 10 19:16:28 int16 kernel: [193201.152522] []
> > xfs_vn_setattr+0x9f/0xb0 [xfs]
> > Oct 10 19:16:28 int16 kernel: [193201.152524] []
> > not
Hi,
On Tue, Oct 02, 2018 at 08:26:12PM +0530, Soji Antony wrote:
> Hello,
>
> We are currently using haproxy 1.8.3 with single process multithreaded
> configuration.
> We have 1 process and 10 threads each mapped to a separate core [0-9]. We
> are running our haproxy instances on a c4.4xlarge aws
Hi Anton,
On Wed, Sep 26, 2018 at 12:09:07PM +0300, prog 76 wrote:
>
> Hi
> First of all Thank you for this great product. We are very happy to use it
> for years.
> Unfortunately from version 1.8.12 we have an issue. Sometimes haproxy crash.
> We tried to upgrade to 1.8.13 and it also crashes.
master, and the
second one for 1.8, as the master patch didn't apply cleanly on 1.8.
Regards,
Olivier
>From d950da31340528c37173fc74d1c0f635c977cd03 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Tue, 11 Sep 2018 14:44:51 +0200
Subject: [PATCH] BUG/MAJOR: kqueue: Don't reset the ch
Hi,
On Tue, Sep 11, 2018 at 12:36:08PM +0200, Lukas Tribus wrote:
> On Tue, 11 Sep 2018 at 11:55, David King wrote:
> >
> > Apologies, i forgot to mention this is running on FreeBSD 11.1
> >
> > I've just run the same tests on Centos and there is no issue
>
> Could you retry with the current dev
On Wed, Sep 05, 2018 at 10:14:55PM +1000, Rob Thomas wrote:
> You gotta wonder how this guy got this mailing list. He must have actually
> LOOKED at the website, right?
>
> Sigh. Spammers.
>
> For anyone who cares, I don't think it's possible for haproxy to get MORE
> exposure on google.
>
> [i
Hi Lukas,
On Fri, Aug 31, 2018 at 02:03:47PM +0200, Lukas Tribus wrote:
> Hello,
>
>
> On Fri, 31 Aug 2018 at 04:30, Willy Tarreau wrote:
> > I'd like to ask you to test something just in case it helps. Could
> > you please modify your makefile to add "-pthread" to "-DUSE_THREAD"
> > like this
On Wed, Aug 29, 2018 at 02:11:45PM +0200, Frederic Lecaille wrote:
> This patch is in relation with one bug reproduced by the reg testing file
> sent by Pieter in this thread:
> https://www.mail-archive.com/haproxy@formilux.org/msg31079.html
>
> Must be checked by Thierry.
> Must be backported to
t;
>
Ok you're right, I have a patch for that problem, which should definitively
be different from Pieter's problem :)
Willy, I think it's safe to be applied, and should probably be backported
(albeit it should be adapted, given the API differences with buffers/channels)
to 1.8 an
On Mon, Aug 27, 2018 at 02:29:42PM +0200, Frederic Lecaille wrote:
> On 08/27/2018 01:33 PM, Olivier Houchard wrote:
> > Hi Pieter,
> >
> > On Sat, Aug 25, 2018 at 10:00:04PM +0200, PiBa-NL wrote:
> > > Hi List, Thierry, Olivier,
> > >
> > >
max_processed = 200
> #8 0x0051a6b2 in run_poll_loop () at src/haproxy.c:2386
> next = 1923608730
> exp = 1923608070
> #9 0x00517672 in run_thread_poll_loop (data=0x8024849f8) at
> src/haproxy.c:2451
> start_lock = {lock = 0, info =
rent state.
>
I think I figured those out, well at least I don't have hangs anymore, and
I think I understood those segfaults.
The attached patchset should do the trick.
Willy, those should be mergeable.
Thanks !
Olivier
>From 159f4653cffdd26fb62a26d047ac3f87f7506e59 Mon Sep 17 00:0
Hi Pieter,
On Mon, Aug 20, 2018 at 09:33:49PM +0200, PiBa-NL wrote:
> Hi Olivier,
>
> Op 17-8-2018 om 14:51 schreef Willy Tarreau:
> > On Fri, Aug 17, 2018 at 01:41:54PM +0200, Olivier Houchard wrote:
> > > That is true, this one is not a bug, but a pessimization, by
On Thu, Aug 16, 2018 at 07:31:17PM +0200, Willy Tarreau wrote:
> Both patches applied, thanks guys!
>
> Olivier, I have a suggestion for this one :
> On Thu, Aug 16, 2018 at 07:17:07PM +0200, Olivier Houchard wrote:
> > From 90fc92f72c6b47d88769bb73680702d7b8e6 Mon Se
Hi again,
On Thu, Aug 16, 2018 at 05:50:27PM +0200, Olivier Houchard wrote:
> Hi Pieter,
>
> On Thu, Aug 16, 2018 at 12:24:04AM +0200, PiBa-NL wrote:
> > Hi List,
> >
> > Anyone got a idea how to debug this further?
> > Currently its running at 100% again, any
Hi Pieter,
On Thu, Aug 16, 2018 at 12:24:04AM +0200, PiBa-NL wrote:
> Hi List,
>
> Anyone got a idea how to debug this further?
> Currently its running at 100% again, any pointers to debug the process as
> its running would be appreciated.
>
> Or should i compile again from current master and 'h
On Wed, Jul 25, 2018 at 09:02:24AM -0400, Julien Semaan wrote:
> Hi Olivier,
>
> Thanks for the time you're taking to check the issue.
>
> I'll get an environment back with TCP splicing enabled and I'll run it in
> GDB and provide you a core dump
>
That would be great, thank you !
Olivier
Hi Julien,
On Tue, Jul 24, 2018 at 01:29:49PM -0400, Julien Semaan wrote:
> > Sorry, that was a "can" that really meant "can't" :) I can't reproduce it.
> Aw well, I was surprised it was so easy :)
>
yea, that would be too easy :)
> > Can you try to upgrade to 1.8.12 ? A number of bugs have
Hi Julian,
On Tue, Jul 24, 2018 at 12:58:27PM -0400, Julien Semaan wrote:
> Hi Olivier,
>
> Glad you're able to replicate it because I can't get it to happen
> consistently!
> I'd be happy if you could share the details of how it could be replicated if
> that's not too complex or hard to explain
Hi Julian,
On Mon, Jul 23, 2018 at 09:07:32AM -0400, Julien Semaan wrote:
> Hi all,
>
> We're currently using haproxy in our project PacketFence
> (https://packetfence.org) and are currently experiencing an issue with
> haproxy segfaulting when TCP splicing is enabled.
>
> We're currently runnin
4d14bce82923cb9b35bb74ac642bb Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Tue, 24 Jul 2018 16:48:59 +0200
Subject: [PATCH] BUG/MINOR: servers: Don't make "server" in a frontend fatal.
When parsing the configuration, if "server", "default-server" or
&quo
Hi,
On Sat, Jul 21, 2018 at 12:51:53AM +0200, Lukas Tribus wrote:
> Hello,
>
> On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote:
> >
> > Hi LuKas,
> >
> > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> > > Hello Oliver,
> &g
Hi LuKas,
On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> Hello Oliver,
>
> On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
> wrote:
> >
> > Hi,
> >
> > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> > > So...is there a way
ed the patch, just using USE_PTHREAD_PSHARED=yes should be enough.
Regards,
Olivier
> On Wednesday, 18 July 2018, 10:45:38 pm AEST, Olivier Houchard
> wrote:
>
> Hi,
>
> On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote:
> > Mea culpa, I applied the patch incorre
Hi,
On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote:
> Mea culpa, I applied the patch incorrectly. After fixing that, I can
> successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes'
> (although from what Olivier said, I probably shouldn't do that). On
> Wednesday, 1
Hi again,
On Tue, Jul 17, 2018 at 01:55:33PM +0200, Olivier Houchard wrote:
> Hi Lukas,
>
> On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote:
> > On Tue, 17 Jul 2018 at 01:09, Thrawn
> > wrote:
> > >
> > > Ah, indeed, the GCC version p
ill
> not work with gcc 3, we did not drop support for gcc3 altogether.
>
>
Unfortunately it is not true. __sync_* was used in include/proto/shctx.h.
The attached patch uses the haproxy macroes instead, and so should get it
to compile again with older gcc. Thrawn, can you please test it ?
T
Hi,
On Mon, Jul 16, 2018 at 01:12:18AM +, Thrawn wrote:
> Update: If I disable threading with
> USE_THREAD=
> then the build gets much further, but still fails eventually with:
> gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o
> ebtree/eb32tree.o ebtree/eb64tree.o ebtree
Hi,
Attached are 2 patches that fix a few bugs in the tasklet code.
It should have little incidence right now because tasklets are unused, but
will be useful for later work.
Regards,
Olivier
>From fd2838a8b4eae2d9801592889285ae221fc3a7cb Mon Sep 17 00:00:00 2001
From: Olivier Houchard
D
Hi Willy,
On Thu, Jun 07, 2018 at 11:45:39AM +0200, Willy Tarreau wrote:
> Hi Olivier,
>
> On Wed, Jun 06, 2018 at 06:40:05PM +0200, Olivier Houchard wrote:
> > You're right indeed, that code was not written with abns sockets in mind.
> > The attached patch should f
ockets
> and ignoring abns sockets where path starts with \0 ?
>
> Using unix socket instead of abns socket makes the reload work.
>
Sorry for the late answer.
You're right indeed, that code was not written with abns sockets in mind.
The attached patch should fix it. It
On Wed, Jun 06, 2018 at 10:06:30AM -0400, Patrick Hemmer wrote:
>
>
> On 2018/6/6 08:24, Olivier Houchard wrote:
> > Hi Willy,
> >
> > On Wed, Jun 06, 2018 at 02:09:01PM +0200, Willy Tarreau wrote:
> >> On Wed, Jun 06, 2018 at 02:04:35PM +0200, Olivier Houchar
1 - 100 of 207 matches
Mail list logo
