On Tue, Oct 9, 2012 at 7:36 AM, Willy Tarreau <[email protected]> wrote:
> On Tue, Oct 09, 2012 at 07:32:01AM +0200, Guillaume Castagnino wrote:
>> Hi,
>>
>> Le lundi 08 octobre 2012 23:06:58 kgardenia42 a écrit :
>> > The problem is that in more than 50% of cases smp_fetch_payload() gets
>> > called when no data has been read from the client. I realize that
>> > normally a load balancer would be in the same data-centre as the pool
>> > members but it still seems like a bug. Do you agree? Actually when
>> > I think about it - I'm not sure how relevant this even is because the
>> > client *is* local to the load balancer and the problem occurs before
>> > the upstream connection is even made so actually I think the upstream
>> > latency may not be a factor at all.
>>
>> Do you have played with the "tcp-request inspect-delay " option ?
>> Unless I'm mistaken, I think it can help you, when doing tcp content
>> inspection.
>
> You're totally right, this is needed in order to wait as long as needed
> for the data. Otherwise the routing decision is taken as soon as possible
> even if there are no data yet.
I did try that and it didn't seem to help.
I can reproduce with the following config:
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
#chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
#debug
#quiet
defaults
log global
mode http
#option httplog
option dontlognull
option redispatch
retries 3
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen mypool :8010
mode tcp
option tcplog
balance roundrobin
stick-table type binary len 36 size 30k expire 1h
stick on payload(10,36)
tcp-request inspect-delay 5s
server pool1 213.167.82.125:80
server pool2 213.167.82.124:80
The pool members are a well known website for testing. Even though
they are HTTP servers I am talking to them using a TCP-ish haproxy
config.
I am running in the foreground as follows:
sudo ./haproxy -V -db -f etc/haproxy.cfg
I compiled with "make TARGET=linux2628" on Ubuntu 12.04
About 50% of the time I will see smp_fetch_payload get called with
when no data has been read and never called again. The reason I know
this is that in smp_fetch_payload I added this line (just before the
"goto too_short" test). Bets way to reproduce is to Ctrl+C and start
again.
fprintf(stderr, "smp_fetch_payload(%u, %u, %u)\n", buf_offset,
buf_size, b->buf.i);
I'm using curl as a test tool:
curl http://localhost:8010
In the bad case I see this:
smp_fetch_payload(10, 36, 0)
In the good case I see this:
smp_fetch_payload(10, 36, 0)
smp_fetch_payload(10, 36, 212)
Even if I set "tcp-request inspect-delay" as high as 10s I get the same thing.
This seems like a bug. Or am I missing something in my config?
Thanks,
Colm
