Francois Rajotte
2016-03-04 17:21:59 UTC
Hi,
I'm having an issue with the client timeout expiring unexpectedly.
I am using haproxy v1.5.14 with the http-keep-alive option.
In my use case, I have a client maintaining a long-lived connection through
haproxy to a backend server. The backend server sends back a response 30
seconds after receiving a request, so I set the server timeout at 60
seconds to be safe. I'm keeping the client timeout at 5 seconds.
What I'm observing is the following:
The client establishes a connection and sends a request.
30 seconds later, the server responds.
Right after receiving the response, the client sends a new request through
the same connection.
5 seconds later, the client timeout expires. In the logs, I see cD-- as the
error code.
When I increase the client timeout to above 30 seconds, then the client
timeout no longer expires.
It was my belief that once the client sends a request, haproxy should no
longer use the client timeout, since as the documentation mentions:
The inactivity timeout applies when the client is expected to acknowledge or
send data.
Since the client has sent its request, it is not expected to send data
and since the server has not sent back anything, the client isn't
expected to acknowledge any data either.
It seems to me that the behavior is correct for the first request on
the connection, but incorrect for the following requests on the same
connection.
For the record, the requests I'm using are not using the "Connection:
keep-alive" headers and the responses are not using the "Connection:
close" header either.
I understand that the documentation specifically mentions that both
the client and server timeouts should be kept equal, but I still don't
understand why I'm seeing client timeouts while waiting for the server
response.
Could someone enlighten me about the inner workings of the client timeout?
Thanks,
François
I'm having an issue with the client timeout expiring unexpectedly.
I am using haproxy v1.5.14 with the http-keep-alive option.
In my use case, I have a client maintaining a long-lived connection through
haproxy to a backend server. The backend server sends back a response 30
seconds after receiving a request, so I set the server timeout at 60
seconds to be safe. I'm keeping the client timeout at 5 seconds.
What I'm observing is the following:
The client establishes a connection and sends a request.
30 seconds later, the server responds.
Right after receiving the response, the client sends a new request through
the same connection.
5 seconds later, the client timeout expires. In the logs, I see cD-- as the
error code.
When I increase the client timeout to above 30 seconds, then the client
timeout no longer expires.
It was my belief that once the client sends a request, haproxy should no
longer use the client timeout, since as the documentation mentions:
The inactivity timeout applies when the client is expected to acknowledge or
send data.
Since the client has sent its request, it is not expected to send data
and since the server has not sent back anything, the client isn't
expected to acknowledge any data either.
It seems to me that the behavior is correct for the first request on
the connection, but incorrect for the following requests on the same
connection.
For the record, the requests I'm using are not using the "Connection:
keep-alive" headers and the responses are not using the "Connection:
close" header either.
I understand that the documentation specifically mentions that both
the client and server timeouts should be kept equal, but I still don't
understand why I'm seeing client timeouts while waiting for the server
response.
Could someone enlighten me about the inner workings of the client timeout?
Thanks,
François
--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.