On Tue, Dec 08, 2009 at 12:29:24AM -0500, Adam Jacob Muller wrote:
> Hi Willy,
> I have right now...
> timeout client 5s
> timeout connect 5s
> timeout server 5s
> option nolinger
It's this one (nolinger).
> listen stats x.x.x.x:8080
> mode http
> stats uri /
> Actually, I just tracked down the issue (partially anyway).
> "option nolinger" is/was causing this.
Ah yes :-)
> Moving nolinger into the frontend block seems to keep the fin_wait1 down and makes the stats page work!
> odd that I never get this issue when haproxy is proxying though, only with the stats page?
Because you're lucky! "nolinger" tells the system that the last data queued in buffers have to be discarded as soon as the connection is closed. I think that you're not seeing it in proxied traffic because your browser closes the connection last, which means it has received those data. But if your browser had closed its output channel first, you would have encountered the same issue. You can have the same problem when testing haproxy's monitor uri from another component.
Do you really have that many fin_wait1 sockets to require the option ? The only case where it was needed (and implemented) was because of a bug in a remote TCP stack used by all the clients. So I find it a bit strange that you need it.
> How nice though that haproxy lets you set such low-level options on a per-request basis!
To be precise it's not on a per-request basis but per-service :-)
> I guess its not really a bug then :)
Indeed. It's just doing what it's supposed to do : drop pending data at the end of the connection.
Willy Received on 2009/12/08 06:38
This archive was generated by hypermail 2.2.0 : 2009/12/08 06:45 CET