Hi,

On Wed, Jun 25, 2014 at 10:00:25AM +0530, Sarvesh Padwal wrote:
> Dear Team,
> 
> We upgraded my haproxy from 1.5dev21 to 1.5.1 stable version with same
> configuartion. At the backend, we are using jBoss.
> As soon as we upgraded, we encountered serious issue regarding jBoss thread
> counts. It has been increased tremendously.
> After rollback to 1.5dev21, everything works fine.
> Please find my below configuration file of haproxy. Kindly suggest any
> changes required to migrate/upgrade to 1.5.1.

Since then we've added support for server-side keep-alive, so it could
be related, though you're working in forceclose mode so you shouldn't
be affected. However, there are no logs in your config, so it's really
hard to guess what could be happening :-/

Did you at least save a copy of the stats page when you first detected
the issue ?

Also, did you see the jboss thread count slowly increase or did you feel
like it went high very fast (as if connections were not closed anymore),
or very slow (as if it was related to health checks) ?

I have a few unrelated comments concerning your configuration below :

> backend backend_http
>         mode http
>         cookie JSESSIONID prefix
>         balance leastconn
>         option forceclose
>         option persist
>         option redispatch
>         option  forwardfor
>         server server3 192.168.58.211:80 cookie server3_cokkie maxconn 1024 
> check

Here you wrote "server3_cokkie" instead of "server3_cookie" as tested in
the ACL below. I think it might be the value you changed by hand before
posting the configuration, but just in case you may want to double-check.

>         server server4 192.168.58.212:80 cookie server4_cookie maxconn 1024 
> check
>         acl force_sticky_server3 hdr_sub(server3_cookie) TEST=true

The way you're using your HTTP headers seems very strange to me, what
I understand here is that in order to force access to server3, you add
a header named "server3_cookie" and put the value "TEST=true" in it. If
so, that's quite ugly. If you pick both 3 and 4, the first one wins. If
for any reason you need to use headers instead of cookies to pick your
server, you should use the same header and put the server name in it,
it will be safer. And better prepend "X-" in front of your custom headers
to avoid messing up with valid ones.

>         force-persist if force_sticky_server3
>         acl force_sticky_server4 hdr_sub(server4_cookie) TEST=true
>         force-persist if force_sticky_server4
>         rspidel  ^Server:.*
>         rspidel  ^X-Powered-By:.*
>         rspidel  ^AMF-Ver:.*
> 
> listen frontend_http *:80
>        mode http
>        maxconn 20000
>        default_backend backend_http

When you have no server, you'd rather declare a "frontend" section
instead of a "listen" section.

> listen frontend_https
>        mode http
>        maxconn 20000
>        bind *:443 ssl crt /opt/haproxy-ssl/conf/ssl/testsite.pem
>        reqadd X-Forwarded-Proto:\ https
>        reqadd X-Forwarded-Protocol:\ https
>        reqadd X-Forwarded-Port:\ 443
>        reqadd X-Forwarded-SSL:\ on
>        acl valid_domains hdr_end(host) -i gateway.testsite.com 
> www.testsite.com m.testsite.com
>        redirect scheme http  if !valid_domains
>        default_backend backend_http if valid_domains

Same here.

Regards,
Willy


Reply via email to