Salut Willy,

> So in fact this "application" pretends to speak HTTP but is not compatible
> with the HTTP spec. You're possibly taking risks by placing HTTP components
> between the client and this thing.
>

Yeah, tell that Adobe. The application we're talking about are Indesign
Server instances.


>   > I'm happy to provide my time/support for you to get in place such an
> > option. Just let me know.
>
> Anyway it will not happen before 1.8 is released and we start to work on
> 1.9, as it would take time away from the already planned features.
>

OK whenever the timing's ready, let me know.


>
> > In the meantime I'll probably try to solve this using iptables limits
> > behind HAProxy (between HAProxy and backend server).
>
> It won't really work.


It does. I've set a REJECT with a connection number above 7 like this (for
each backend server obvisously):
iptables -A OUTPUT -p tcp --syn -d 10.10.10.12/32 --dport 18390 -m
connlimit --connlimit-above 7 -j REJECT --reject-with tcp-reset

The only downside I see with this setup is that the healthcheck from
HAProxy returns a L4TOUT when 7 connections are already in use by the
(application-)client. The 8th connection (healthcheck coming from HAProxy)
is rejected by iptables.

I'm aware that I'm working around the issue here, but so far this is the
closest solution I came up with to meet the application requirements.


> There might be something which can work, which is
> to chain to a TCP listener. It will enforce the maxconn count at the TCP
> level. By having this  :
>
>   listen foo
>      mode http
>      ...
>      server app02-1 127.0.0.1:10001
>      server app02-2 127.0.0.1:10002
>      server app02-3 127.0.0.1:10003
>
>   listen app02-1
>      mode tcp
>      bind 127.0.0.1:10001
>      server app02-1 10.10.10.12:12345 maxconn 6 maxqueue 0
>
>   listen app02-2
>      mode tcp
>      bind 127.0.0.1:10002
>      server app02-1 10.10.10.12:12346 maxconn 6 maxqueue 0
>
>   ...
>
> By the way, looking at your config, I'm now wondering why
> you are using HTTP mode in your frontend/backend instead of
> TCP mode. You're adding a cookie but you mentionned that the
> application doesn't support requests being mixed over connections
> so I guess that the stickiness is only ensured at the connection
> level and the cookie very likely is useless. Then by using only
> "mode tcp" you could have exactly what you need, ie: maxconn
> enforced at the TCP level.
>


This is a very good idea, but I don't think it would work.
I wrote in another mailing list thread before, that once a connection was
send to a backend server, all future requests MUST go to the same backend
server again (no failover, no balancing - a stale and fixed connection
between client and backend server).
To my current knowledge, this is only possible by setting a cookie which
can only be read in http mode. And "balance source" in this case won't
help, because the source IP of the client will be the same.
If I'm mistaken, please let me know.


In your tcp example I just noticed "maxqueue 0". Does this actually disable
the queue? I asked this in my previous mailing list thread :)

cheers,
ck

Reply via email to