Hi!
It seems to me there is something wrong with this patch: for some reason
process stops responding with 100% CPU used by all threads.
Backtrace:
(gdb) thread apply all bt
Thread 4 (Thread 0x7fdf68c9c700 (LWP 615744)):
#0 0x564fc9a61990 in fwrr_update_server_weight (srv=0x564fcb5014b0) at
On Wed, Apr 24, 2019 at 12:30:36AM +0500, ??? wrote:
> > http://git.haproxy.org/?p=haproxy.git;a=commit;h=333939c2eee8f9dbfe11f66073e52892b38347e7
> >
> > This one was just found and fixed by Fred. Just pushed as commit bed883ab.
> >
>
> there're seem to be more regressions. I can run
вт, 23 апр. 2019 г. в 23:25, Willy Tarreau :
> On Tue, Apr 23, 2019 at 10:31:05PM +0500, ??? wrote:
> > Hello, Baptise!
> >
> > we have enabled travis-ci builds on haproxy master branch. seems we have
> a
> > regression here:
> >
> >
>
On Tue, Apr 23, 2019 at 10:31:05PM +0500, ??? wrote:
> Hello, Baptise!
>
> we have enabled travis-ci builds on haproxy master branch. seems we have a
> regression here:
>
> http://git.haproxy.org/?p=haproxy.git;a=commit;h=333939c2eee8f9dbfe11f66073e52892b38347e7
This one was just found
yep, I'm going to invest some time in building openssl matrix on travis-ci,
i.e. openssl-1.0, 1.0.2, 1.1.1, libressl, ...
вт, 23 апр. 2019 г. в 22:31, Willy Tarreau :
> On Tue, Apr 23, 2019 at 10:11:09PM +0500, ??? wrote:
> > I want to bisect in order to find offending commit.
> > we've
this particular regression is reproduced on my fedora laptop, which is
openssl-1.1.X
вт, 23 апр. 2019 г. в 22:31, Willy Tarreau :
> On Tue, Apr 23, 2019 at 10:11:09PM +0500, ??? wrote:
> > I want to bisect in order to find offending commit.
> > we've got regression. it need to be fixed,
Hello, Baptise!
we have enabled travis-ci builds on haproxy master branch. seems we have a
regression here:
http://git.haproxy.org/?p=haproxy.git;a=commit;h=333939c2eee8f9dbfe11f66073e52892b38347e7
can you have a look please ?
failing build (we have enabled them just recently):
On Tue, Apr 23, 2019 at 10:11:09PM +0500, ??? wrote:
> I want to bisect in order to find offending commit.
> we've got regression. it need to be fixed, no need to mark it as "allowed
> failure"
Got it. We've spotted issues with SSL that affect openssl < 1.1, and
very likely related to
I want to bisect in order to find offending commit.
we've got regression. it need to be fixed, no need to mark it as "allowed
failure"
вт, 23 апр. 2019 г. в 22:00, Willy Tarreau :
> On Tue, Apr 23, 2019 at 09:20:52PM +0500, ??? wrote:
> > let us wait for a while and do not enable "allow
On Tue, Apr 23, 2019 at 09:20:52PM +0500, ??? wrote:
> let us wait for a while and do not enable "allow failures".
That's unclear to me Ilya, do you mean you prefer that we wait a bit
more without taking it, that's it ? I'm fine with all options.
Willy
Hi,
We've noticed that our haproxy processes accumulate many file descriptors to
/dev/urandom over time. This coincidences with reloads;
rnewson@lb2:~$ sudo service haproxy restart
rnewson@lb2:~$ sudo ls -l /proc/$(pgrep -o haproxy)/fd | grep -c '/dev/urandom'
1
rnewson@lb2:~$ sudo ls -l
let us wait for a while and do not enable "allow failures".
вт, 23 апр. 2019 г. в 20:24, Willy Tarreau :
> On Tue, Apr 23, 2019 at 04:41:44PM +0200, Tim Düsterhus wrote:
> > List,
> >
> > Am 23.04.19 um 16:40 schrieb Tim Duesterhus:
> > > [...]
> >
> > Sorry for the noise. This v2 only differs
On Tue, Apr 23, 2019 at 04:41:44PM +0200, Tim Düsterhus wrote:
> List,
>
> Am 23.04.19 um 16:40 schrieb Tim Duesterhus:
> > [...]
>
> Sorry for the noise. This v2 only differs by a non-unicode author name.
> The 'ü' slipped in, because I initially developed this patch using GitHub.
OK :-)
I'm
List,
Am 23.04.19 um 16:40 schrieb Tim Duesterhus:
> [...]
Sorry for the noise. This v2 only differs by a non-unicode author name.
The 'ü' slipped in, because I initially developed this patch using GitHub.
Best regards
Tim Düsterhus
This commit extends the Travis CI configuration to build HAProxy with
gcc on Linux, clang on Mac and cleans up the build flag configuration to
be easier extendable.
Note: At the moment HAProxy fails on Travis for two configurations
- on Linux with build flags enabled
- on OS X
Thus these two
From: Tim Düsterhus
This commit extends the Travis CI configuration to build HAProxy with
gcc on Linux, clang on Mac and cleans up the build flag configuration to
be easier extendable.
Note: At the moment HAProxy fails on Travis for two configurations
- on Linux with build flags enabled
- on OS
Hey,
we have an older setup using nbproc >1 and having a listener for the
initial tcp connection and one for the actual SSL/TLS, also using tcp
mode which then goes to the actual frontend using http mode. Each being
bound to different processes.
So here's the test config I've used:
listen
Le 20/04/2019 à 12:15, Kevin Zhu a écrit :
Hi
I think there forgot check if the spoe_context already has fragment msg
send before spoe_queue_context, it will segment fault
in spoe_release_appctx.
This bug is already fixed, in the upstream (3e86cec05) and HAProxy 1.9
(c3468fe1d). However,
Le 13/04/2019 à 09:53, Kevin Zhu a écrit :
The processing is really difficult to be smaller than
processing_per_sec, and most msg will create a new applet, but there are
already have a lot idle applets waiting for work. and the result is that
the most applets is not reused.
This patch should
Le 10/04/2019 à 08:44, Kevin Zhu a écrit :
-- Forwarded message -
From: *Kevin Zhu* mailto:ip0...@gmail.com>>
Date: Wed, 10 Apr 2019 at 14:25
Subject: Re: haproxy1.9, SPOA: too many open files
To: Christopher Faulet mailto:cfau...@haproxy.com>>
Thinks reply.
OS: CentOS Linux
вт, 23 апр. 2019 г. в 14:50, Willy Tarreau :
> Hi Tim,
>
> On Tue, Apr 23, 2019 at 11:28:22AM +0200, Tim Düsterhus wrote:
> > No real management necessary.
> (...)
> > Ideally you should not notice anything: It means no one commited bad
> > code. It might need some adjustments in the beginning,
Hi Tim,
On Tue, Apr 23, 2019 at 11:28:22AM +0200, Tim Düsterhus wrote:
> No real management necessary.
(...)
> Ideally you should not notice anything: It means no one commited bad
> code. It might need some adjustments in the beginning, very similar to
> the issue tracker :-)
OK that's the
On Thu, Apr 18, 2019 at 10:49:29AM +0200, Baptiste wrote:
> Hi all, Willy,
>
> Please find attached to this email the 4 patches for the http-request
> do-resolve action I submitted a few months ago.
> I integrated all feedback from Willy and also now support tcp-request
> content do-resolve.
Now
Willy,
I'll chime in here.
Am 23.04.19 um 11:16 schrieb Willy Tarreau:
> On Mon, Apr 22, 2019 at 10:13:52PM +0500, ??? wrote:
>> I can enable travis-ci by myself if you can temporarily grant me an access
>> to github repo
>
> I'm not against doing this, it's just that I still have no
Hi!
On Mon, Apr 22, 2019 at 10:58:59AM +0200, Lukas Tribus wrote:
> This is why thread support was introduced though. Using threads
> instead of processes fixes this. Achieving the same performance with
> threads will require some tuning, but at the end you'll end up with a
> simple and scalable
Hi Ilya,
On Mon, Apr 22, 2019 at 10:13:52PM +0500, ??? wrote:
> I can enable travis-ci by myself if you can temporarily grant me an access
> to github repo
I'm not against doing this, it's just that I still have no idea what
the impacts are. In short, will any of us get any extra work
Hi Paul,
On Fri, Apr 19, 2019 at 06:45:22PM +0200, Paul Stephen Borile wrote:
> Hi Willy,
>
> fine for me, thanks for the adjustments and no problem backporting this to
> 1.9.
> I also confirm that the contact email address is working correctly.
Fine thank you. I could finish the polishing (add
27 matches
Mail list logo
