Thank you, Willy.
We'll update the version as soon as possible and test if the behavior is the
same.
To understand it well, is compatible a result 200 by the server with a state
"Q" in logs ?
Best regards
-----Mensaje original-----
De: Willy Tarreau <w...@1wt.eu>
Enviado el: lunes, 4 de febrero de 2019 18:48
Para: Juan Pablo Mora <juanpablo.m...@logalty.com>
CC: haproxy@formilux.org
Asunto: Re: cQ-- termination state doubts
Hi,
On Mon, Feb 04, 2019 at 04:05:15PM +0000, Juan Pablo Mora wrote:
>
> During a period of slowness of my database I see this log (HAProxy 1.7.5):
>
>
> Feb 4 11:09:30 localhost.localdomain haproxy[23601]:
> 185.198.176.21:41987 [04/Feb/2019:11:09:12.408] WWW BUS/BUS2
> 9/8785/2/8860/17657 200 596 8453 - - cQ-- 528/236/37/14/0 0/9
> {|3701F3DB6BBF1DAC} {|RESULT_OK_HEADER} "POST /Service HTTP/1.1" TLSv1
>
>
> My timeouts configs are:
>
> defaults
> timeout connect 4s
> timeout client 5s
> timeout server 30m
> timeout http-request 10s
> timeout http-keep-alive 3s
>
> backend BUSINCOMING
> option forwardfor
>
> timeout connect 5s
> timeout server 2m
> timeout queue 30s
>
> http-request deny if { hdr_cnt(content-length) gt 0 } {
> hdr_val(content-length) gt 31457280 } # 30M
>
> server BUS1 po_emi_0:18001 maxconn 15
> server BUS2 ix_emi_0:18001 maxconn 15
>
> The request ends with 200, request and response headers was captured.
> If it was a timeout client, Why isn't there a -1 in some timer? And how the
> "Q"
> termination state can be explained?
I think you've met a corner case here. The client timeout has probably
triggered during the upload but the request was already in the queue and was
sent as is and processed by the server. But the most likely cause is that in
fact the request was complete, the client timeout should have been disabled but
it wasn't and it triggerred while the request was waiting in the queue.
How does it behave on more up to date versions ? (this one is missing many
fixes).
Thanks,
Willy
