On 19/04/16 18:52, Willy Tarreau wrote:
On Tue, Apr 19, 2016 at 04:15:08PM +0200, Willy Tarreau wrote:
OK in fact it's different. Above we have a busy polling loop, which may
very be caused by the buffer space miscalculation bug and which results
in a process not completing its job until a timeou
2016-04-19 18:13 GMT+02:00 Emeric Brun :
> I don't know how the curve negotiation works, but i have some questions.
>
> What is the behavior if the SSL_CTX_set_ecdh_auto is used on server side and
> if
> the client doesn't support the neg.
>
> In other words:
>
> Is it useful to set both SSL_CTX_s
Hello Michael,
On Fri, Apr 15, 2016 at 11:39:35PM +0200, Michael Rennecke wrote:
> Hello,
>
> I know this question is stupid. Is there a coding style for config
> files, like this: http://www.haproxy.org/coding-style.html ?
No and that could be a very good idea. In general everyone tends to
adop
Hi Nenad,
On Sun, Apr 17, 2016 at 12:05:04AM +0200, Nenad Merdanovic wrote:
> This is very useful in complex architecture systems where HAproxy
> is balancing DB connections for example. We want to keep the maxconn
> high in order to avoid issues with queueing on the LB level when
> there is slown
On 04/18/2016 11:23 PM, David Martin wrote:
> On Mon, Apr 18, 2016 at 3:02 PM, Janusz Dziemidowicz
> wrote:
>> 2016-04-15 16:50 GMT+02:00 David Martin :
>>> I have tested the current patch with the HAProxy default, a list of curves,
>>> a single curve and also an incorrect curve. All seem to beha
On Tue, Apr 19, 2016 at 04:15:08PM +0200, Willy Tarreau wrote:
> On Tue, Apr 19, 2016 at 02:54:35PM +0200, Lukas Tribus wrote:
> > >We use haproxy 1.6.3 (latest CentOS 6.7) and experience similar situation
> > >after some reloads (-sf). The old haproxy process does not exit and uses
> > >100% cpu,
Hi guys,
On Tue, Apr 19, 2016 at 02:54:35PM +0200, Lukas Tribus wrote:
> >We use haproxy 1.6.3 (latest CentOS 6.7) and experience similar situation
> >after some reloads (-sf). The old haproxy process does not exit and uses
> >100% cpu, strace showing:
> >epoll_wait(0, {}, 200, 0) =
Hi,
Am 19.04.2016 um 15:10 schrieb CJ Ess:
That will work for now, in the future it wold be nice to have an
option to allow non-control utf-8 characters in the URI without
enabling all of the other stuff.
Thats exactly what this option already does.
There is fortunately no way in haproxy to
That will work for now, in the future it wold be nice to have an option to
allow non-control utf-8 characters in the URI without enabling all of the
other stuff.
On Mon, Apr 18, 2016 at 4:59 PM, PiBa-NL wrote:
> Op 18-4-2016 om 22:47 schreef CJ Ess:
>
> This is using HAProxy 1.5.12 - I've notic
Hi,
Am 19.04.2016 um 09:39 schrieb Veiko Kukk:
We use haproxy 1.6.3 (latest CentOS 6.7) and experience similar
situation after some reloads (-sf). The old haproxy process does not
exit and uses 100% cpu, strace showing:
epoll_wait(0, {}, 200, 0) = 0
epoll_wait(0, {}, 200, 0)
On 16/04/16 01:53, Jim Freeman wrote:
I'm suspecting that a connection to the stats port goes wonky with a
'-sf' reload, but I'll have to wait for it to re-appear to poke
further. I'll look first for a stats port connection handled by the
pegged process, then use 'tcpkill' to kill just that con
11 matches
Mail list logo
