Hi:
Thanks for the quick response. We changed the configuration as follows and it
still does not work. The problem seems to be getting the response payload and
comparing it against letter "5". We have also tried upgrading to 1.7.9 and face
the same issue. The stick table does not get updated
Hi Pieter,
On Sun, Nov 19, 2017 at 11:35:26PM +0100, PiBa-NL wrote:
> Was using this: make clean build reinstall NO_CHECKSUM=yes WITH_DEBUG=yes
> STRIP=
>
> So it would have debug symbols if problems would arise..
> The "WITH_DEBUG=yes" strips the -O2 away and makes it a -g and thus
>
On Sun, Nov 19, 2017 at 10:43:21PM +0100, Willy Tarreau wrote:
> Your workaround has disabled locking so you'll get random bugs if you enable
> threads. Could you please send the output of "cc -v" ? That should help
> figure how this situation is possible. In the mean time you can build with
>
Hi Pieter,
On Sun, Nov 19, 2017 at 05:35:36PM +0100, PiBa-NL wrote:
> Hi haproxy-list,
>
> I'm trying to build 1.8rc4 on FreeBSD 11.1, but it throws a few errors for
> me..
>
> src/listener.o: In function `listener_accept':
>
Hi haproxy-list,
I'm trying to build 1.8rc4 on FreeBSD 11.1, but it throws a few errors
for me..
src/listener.o: In function `listener_accept':
/usr/ports/net/haproxy-devel/work/haproxy-1.8-rc4/src/listener.c:455:
undefined reference to `__unsupported_argument_size_for_pl_try_s__'
Hi Willy,
The 60 second expire bug disappeared when I set the opiton
http-buffer-request on. However after that we started seeing intermittent
socket connection expired from our android clients. No matter what we set
the expiration to this happens like every 10 minutes or so. The error lasts
a
Thanks.
I found another very useful way.
Since 1.7 version, set-var can be in process scope.
In this way, I can set and transfer variables from one front-end to another
front-end.
JWD
From: Aleksandar Lazic
Date: 2017-11-19 18:35
To: JWD; haproxy
Subject: Re: Is it possible to transfer
Willy,
Am 19.11.2017 um 10:21 schrieb Willy Tarreau:
> *snip*
It looks like you made an accidental change to doc/peers.txt in commit
cfe14669f7f05c6b0d70eaa64944bcbcaa963218:
> diff --git a/doc/peers.txt b/doc/peers.txt
> index f31d937e3..8310a0016 100644
> --- a/doc/peers.txt
> +++
Willy,
Am 19.11.2017 um 07:32 schrieb Willy Tarreau:
> Tim, I'll discuss this with William. I'm a bit embarrassed with taking
> this change right now while everyone is still working on fixing existing
> issues.
Understood. I see that my timing is unfortunate, but I just got my feet
wet with the
Hi Danny,
So I had a look at this issue which is easily reproducible.
See my answer below.
On 11/12/2017 07:43 PM, my.card@web.de wrote:
Hi,
I've figured it out, it has been a feature of the dissector code.
Perhaps it might be useful for someone developing her own SPOA.
Kind regards,
Hello,
2017-11-19 11:09 GMT+01:00 Haim Ari :
>
> Hello,
>
>
> Our haproxy sends logs through rsyslog (UDP) many messages are "chopped"
> after ~ 1300 characters
>
> After some testing i think the limit is MTU
>
>
> What would be the right way to handle this so that all
Hi.
-- Originalnachricht --
Von: "Willy Tarreau"
An: haproxy@formilux.org
Gesendet: 19.11.2017 10:21:36
Betreff: [ANNOUNCE] haproxy-1.8-rc4
Hi everyone!
So it's getting better. When fixing the scheduler issues in the last
RC, I messed up with the tree traversal, leading
Ho JWD
-- Originalnachricht --
Von: "JWD"
An: "haproxy"
Gesendet: 19.11.2017 04:51:05
Betreff: Is it possible to transfer client ip (src) from ssl:443 to
https:8443?
client access ssl:443.
https:8443 as backend of ssl:443.
Is it possible to
Hello,
Our haproxy sends logs through rsyslog (UDP) many messages are "chopped" after
~ 1300 characters
After some testing i think the limit is MTU
What would be the right way to handle this so that all messages (~3K) will
arrive correctly through UDP?
Details:
Ubuntu 16.04
HAProxy
Hi everyone!
So it's getting better. When fixing the scheduler issues in the last
RC, I messed up with the tree traversal, leading to some tasks waiting
in the run queue without being found for a while. This was causing some
timeouts and occasionally 100% CPU during normal operation. This is now
15 matches
Mail list logo