Hi Sander,
On Fri, Apr 05, 2013 at 02:51:54PM +0200, Sander Klein wrote:
> Hi Lukas,
>
> On 05.04.2013 12:00, Lukas Tribus wrote:
> >Whats is the percentage of requests failing this way?
>
> I'm not sure. But I think it's less than 1%. We do a couple of 100's
> request per second and about every second I see one failed request.
>
> >Do you know if this is an issue introduced by a certain haproxy build,
> >and thus
> >was working previously, or did you only recently enable splice-auto?
> >Are you able to reproduce this in dev17 or in stable 1.4.23 (but you
> >probably
> >rely on 1.5 features)?
>
> I cannot try 1.4 because I indeed rely on 1.5 features. But I did try
> dev18 and dev17-ss-20130125. Both give the same problems. I cannot go
> any further back because I had some issues with versions before 20130125
> if I recall correctly. I'm not sure what is was anymore :-)
Could you test if the following patch fixes the problem ? It comments out
an optim that was merged in 20130107 (before the snapshot you describe)
but now I'm having a doubt about it : I think that if the input pipe is
full just before storing the whole response, and the server closes along
with the response, it might result in truncating it to the pipe's size.
Thanks,
Willy
diff --git a/src/raw_sock.c b/src/raw_sock.c
index ad4a0aa..6b9a13d 100644
--- a/src/raw_sock.c
+++ b/src/raw_sock.c
@@ -161,8 +161,8 @@ int raw_sock_to_pipe(struct connection *conn, struct pipe
*pipe, unsigned int co
pipe->data += ret;
/* if a POLL_HUP was present, we've read the last segment */
- if ((fdtab[conn->t.sock.fd].ev & (FD_POLL_ERR|FD_POLL_HUP)) ==
FD_POLL_HUP)
- goto out_read0;
+ //if ((fdtab[conn->t.sock.fd].ev & (FD_POLL_ERR|FD_POLL_HUP))
== FD_POLL_HUP)
+ // goto out_read0;
if (pipe->data >= SPLICE_FULL_HINT || ret >=
global.tune.recv_enough) {
/* We've read enough of it for this time, let's stop
before
