Hi Ludovico,
On Mon, Apr 27, 2015 at 10:54:43AM -0700, Ludovico Cavedon wrote:
> Hi Willy,
>
> On Wed, Apr 22, 2015 at 10:58 AM, Ludovico Cavedon
> wrote:
>
> > I will let you know, thanks again!
> >
> >
> I reproduced your test case and it turned out the abortonclose option was
> only in the l
Hi Willy,
On Wed, Apr 22, 2015 at 10:58 AM, Ludovico Cavedon
wrote:
> I will let you know, thanks again!
>
>
I reproduced your test case and it turned out the abortonclose option was
only in the listener section (and not on backend/defautls).
I moved it to "defaults" and now haproxy is behaving
Hi Willy,
thank you for the very detailed information.
On Wed, Apr 22, 2015 at 8:57 AM, Willy Tarreau wrote:
> That's normal, this is httpterm and it doesn't monitor the connection while
> it's waiting. But in your case it should definitely work. Or it means that
> your server ignores the clien
Hi again Ludovico,
so I ran some tests here with latest 1.5. I telnet to haproxy, send
"GET /?t=1 HTTP/1.1" then quit. It forwards to a server which
waits 10s before responding.
First, without "option abortonclose" :
17:47:40.174784 accept4(7, {sa_family=AF_INET, sin_port=htons(53833),
sin_
Hi Ludovico,
On Fri, Apr 17, 2015 at 08:24:43PM -0700, Ludovico Cavedon wrote:
> Hi,
>
> I am trying to find a solution to the following issue.
>
> I have a client A that sends hundreds of HTTP requests per second to
> server B running ha-proxy 1.5.3.
> Server B/haproxy forwards them to server C
Hi,
I am trying to find a solution to the following issue.
I have a client A that sends hundreds of HTTP requests per second to
server B running ha-proxy 1.5.3.
Server B/haproxy forwards them to server C.
Some of these request are long-polling: server C will receive the
request and hang for a ve
6 matches
Mail list logo
