Hi List,
With the config below while running 'siege' i get a core dump within a
few hundreds of requests.. Viewing the stats page from a chrome browser
while siege is running seems to crash it sooner..
Is below enough to find the cause? Anything else i should try?
Using the haproxy snapshot
Hi,
Le 01/10/2015 20:52, PiBa-NL a écrit :
Hi List,
With the config below while running 'siege' i get a core dump within a
few hundreds of requests.. Viewing the stats page from a chrome browser
while siege is running seems to crash it sooner..
Is below enough to find the cause? Anything else
Hi,
small update on the repro..
Op 1-10-2015 om 23:00 schreef Cyril Bonté:
Hi,
Le 01/10/2015 20:52, PiBa-NL a écrit :
Hi List,
With the config below while running 'siege' i get a core dump within a
few hundreds of requests.. Viewing the stats page from a chrome browser
while siege is running
Hi again,
File attached with console 'debug' output, and its backtrace(looks +-
the same as before). This time it crashed after only a 'few' 108
requests, maybe it helps.?.
This happened while running with ab and keepalive: ab -k -r -c 100 -n
5 http://192.168.0.112:801/
Op 1-10-2015 om 2
Hi,
I process this email later. For waiting, I propose to you to set the
"option http-server-close". Actually, the "services" doesn't support
itself the keepalive, but HAProxy does this job.
The "option http-server-close" expectes a server-close from the service
stream. The front of HAProxy maint
Hi Thierry,
With or without "option http-server-close" does not seem to make any
difference.
Adding a empty backend does seem to resolve the problem, stats also show
the backend handling connections and tracking its 2xx http result
session totals when configured like this.:
frontend http_f
On Mon, 5 Oct 2015 21:04:08 +0200
PiBa-NL wrote:
> Hi Thierry,
Hi Pieter,
> With or without "option http-server-close" does not seem to make any
> difference.
Sure, it is only an answer to the Cyril keep alive problem. I encounter
again the keepalive problem :(
The HAProxy applet (services
Hi Thierry,
Op 6-10-2015 om 9:47 schreef Thierry FOURNIER:
On Mon, 5 Oct 2015 21:04:08 +0200
PiBa-NL wrote:
Hi Thierry,
Hi Pieter,
With or without "option http-server-close" does not seem to make any
difference.
Sure, it is only an answer to the Cyril keep alive problem. I encounter
agai
Hi All,
Op 7-10-2015 om 0:31 schreef PiBa-NL:
Hi Thierry,
Op 6-10-2015 om 9:47 schreef Thierry FOURNIER:
On Mon, 5 Oct 2015 21:04:08 +0200
PiBa-NL wrote:
Hi Thierry,
Hi Pieter,
With or without "option http-server-close" does not seem to make any
difference.
Sure, it is only an answer t
Hi Pieter,
On Mon, Oct 12, 2015 at 01:22:48AM +0200, PiBa-NL wrote:
> >>#1 0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
> >>src/buffer.c:166
> >> block1 = -3306
> >> block2 = 0
I'm puzzled by this above, no block should have a negative size.
>
Hi Willy,
Op 12-10-2015 om 7:28 schreef Willy Tarreau:
Hi Pieter,
On Mon, Oct 12, 2015 at 01:22:48AM +0200, PiBa-NL wrote:
#1 0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
src/buffer.c:166
block1 = -3306
block2 = 0
I'm puzzled by this above, no block shoul
Hi Pieter,
On Mon, Oct 12, 2015 at 10:29:05PM +0200, PiBa-NL wrote:
> Been running some more tests with the information that req->buf->i
> should be >= 0.
>
> What i find is that after 1 request i already see rqh=-103 , it seems
> like the initial request size which in this case is also is 103
Hi Willy,
Op 12-10-2015 om 23:06 schreef Willy Tarreau:
Hi Pieter,
On Mon, Oct 12, 2015 at 10:29:05PM +0200, PiBa-NL wrote:
Been running some more tests with the information that req->buf->i
should be >= 0.
What i find is that after 1 request i already see rqh=-103 , it seems
like the initial
On Tue, Oct 13, 2015 at 12:32:08AM +0200, PiBa-NL wrote:
> >Yep so here rqh is in fact req->buf->i and as you noticed it's been
> >decremented a second time.
> >
> >I'm seeing this which I find suspicious in hlua.c :
> >
> > 5909
> > 5910 /* skip the requests bytes. */
> > 59
On Tue, 13 Oct 2015 00:46:43 +0200
Willy Tarreau wrote:
> On Tue, Oct 13, 2015 at 12:32:08AM +0200, PiBa-NL wrote:
> > >Yep so here rqh is in fact req->buf->i and as you noticed it's been
> > >decremented a second time.
> > >
> > >I'm seeing this which I find suspicious in hlua.c :
> > >
> > >
Hi guys,
On Tue, Oct 13, 2015 at 10:07:33AM +0200, Thierry FOURNIER wrote:
> I'm silently following the thread :) I can't reproducethe issue, I
> supposed that is because it appears on FreeBSD, but I suppose that it
> will be appear on Linux.
>
> Westerday my laptop were out of battery, so it reb
Hi again :-)
On Tue, Oct 13, 2015 at 06:10:33PM +0200, Willy Tarreau wrote:
> I can't reproduce either unfortunately. I'm seeing some other minor
> issues related to how the closed input is handled and showing that
> pipelining doesn't work (only the first request is handled) but that's
> all I'm
Hi Willy, Thierry, others,
Op 13-10-2015 om 18:29 schreef Willy Tarreau:
Hi again :-)
On Tue, Oct 13, 2015 at 06:10:33PM +0200, Willy Tarreau wrote:
I can't reproduce either unfortunately. I'm seeing some other minor
issues related to how the closed input is handled and showing that
pipelining
Hi Pieter,
On Wed, Oct 14, 2015 at 01:43:40AM +0200, PiBa-NL wrote:
> Ok got some good news here :).. 1.6.0-release nolonger has the error i
> encountered.
>
> The commit below fixed the issue already.
> --
> CLEANUP: cli: ensure we can never double-free error messages
> http://git.haproxy.org/?
On Wed, 14 Oct 2015 05:39:58 +0200
Willy Tarreau wrote:
> Hi Pieter,
>
> On Wed, Oct 14, 2015 at 01:43:40AM +0200, PiBa-NL wrote:
> > Ok got some good news here :).. 1.6.0-release nolonger has the error i
> > encountered.
> >
> > The commit below fixed the issue already.
> > --
> > CLEANUP: cl
20 matches
Mail list logo