Thank you, works like a charm !
2011/11/30 Willy Tarreau
> On Wed, Nov 30, 2011 at 06:10:29PM +0200, Daniel Rankov wrote:
> > Hi, Thank you, these explonations are really helpfull.
> > Now may be because of a bug or something but "option nolinger" is not
> > working for backend. it works great f
On Wed, Nov 30, 2011 at 06:10:29PM +0200, Daniel Rankov wrote:
> Hi, Thank you, these explonations are really helpfull.
> Now may be because of a bug or something but "option nolinger" is not
> working for backend. it works great for frontend. And I've tested putting
> this option all over the conf
Hi, Thank you, these explonations are really helpfull.
Now may be because of a bug or something but "option nolinger" is not
working for backend. it works great for frontend. And I've tested putting
this option all over the config file... That's is what had confused me.
OS is centos6, HA-Proxy ver
On Wed, Nov 30, 2011 at 03:56:14PM +0200, Daniel Rankov wrote:
> Ok, now I'm kind of stuck here.
> Let me share you my observations on my really simple evirionment:
> for client I use wget on server with ip 192.168.2.30
> haproxy is set on server with ip 192.168.2.38
> and haproxy and web serer com
Ok, now I'm kind of stuck here.
Let me share you my observations on my really simple evirionment:
for client I use wget on server with ip 192.168.2.30
haproxy is set on server with ip 192.168.2.38
and haproxy and web serer comunicate on 127.0.0.1. haproxy is in tcpmode.
this is the monitored tcpdum
Hi Daniel,
On Tue, Nov 29, 2011 at 06:10:46PM +0200, Daniel Rankov wrote:
> For sure TIME_WAIT connections are not an issue when thay keep information
> about sockets to clients, but when TIME_WAIT connections keep sockets bussy
> for your host where HAProxy is deployed to the backend the limit ca
For sure TIME_WAIT connections are not an issue when thay keep information
about sockets to clients, but when TIME_WAIT connections keep sockets bussy
for your host where HAProxy is deployed to the backend the limit can be
reached - it's defined by ip_local_port_range.
Here is what I mean:
Client -
I would preffer not to use tw_reuse, couse that will affect the whole
server tcp comunication, not just one process (HAProxy in this case).
So I've tested nolinger but what it does isn't completely the solution.
That's what happens when ising it - lets say that client is closing the
connection to H
On Mon, Nov 28, 2011 at 12:28 PM, Daniel Rankov wrote:
> Yeap, I'm aware of net.ipv4.tcp_tw_reuse and the need of TIME_WAIT state,
> but still if there is a way to send a RST /either configuration or compile
> parameter/ the connection will be destroyed.
>
TIME_WAIT is usually not a problem if po
Yeap, I'm aware of net.ipv4.tcp_tw_reuse and the need of TIME_WAIT state,
but still if there is a way to send a RST /either configuration or compile
parameter/ the connection will be destroyed.
2011/11/28 James Bardin
> On Mon, Nov 28, 2011 at 11:50 AM, Daniel Rankov
> wrote:
> And on
> > loa
On Mon, Nov 28, 2011 at 11:50 AM, Daniel Rankov wrote:
And on
> loaded server this will cause trouble. Isn't there a chance for HAProxy to
> send RST, so that conneciton will be dropped ?
An RST packet won't make the TIME_WAIT socket disappear. It's part if
the TCP protocol, and a socket will si
Hi,
I'm testing HAProxy.
Now, what I came up with and it's a real bothering me is that there are a
lot of network connections type TIME_WAIT.
Here is my environment - on CentOS 6 server I've set up HAProxy in tcp mode
to split connections between 2 web servers with SSL / Jetty web server /.
All th
12 matches
Mail list logo
