Hi Conrad,
> Hey all,
>
> can someone give me a very brief summary of how haproxy handles its
> connection pooling when the backend server sends "Connection: close"
> and/or HTTP/1.0?
Simple: there is no connection pooling at all (yet). When a backend emits
"Connection: close":
- the "Connection: close" is propagated to the client
- all connections belonging to that session (both front and backend) are
closed.
> Or, to be more specific, we have (for certain traffic) an haproxy
> instance as backend for another haproxy. We are seeing huge increases in
> "sessions_cur" when one of the all-the-way-back-ends fail. I noticed
> that haproxy itself responds with HTTP/1.0 and "Connection: close" when
> a backend is unavailable. Would that mess with the connection pooling of
> the front-most haproxy? And, if so, would there any way to change this
> behaviour?
>
> We cannot rule out that this is an issue caused by how clients react to
> the errors, but I would nevertheless love to gain some insight into this
> scenario. Any hints would be greatly appreciated!
Well, since the connection is closed, the client will probably retry and if
there is no backup backend that can serve the connection, the client may
continuously retry, some more aggressively than others, depending on browser
and application I suspect.
I'm not sure what you expect to happen? Do you have a backup backend
that can take the load when the primary fails? Then there should be no
problem because the client (when retrying) will be switched to the secondary
backend, and everything will work fine. Otherwise, if there is no secondary
backend, the application will not work anyway.
If maxconn is properly configured, an increase in sessions_cur should not
lead to any problems.
Regards,
Lukas
