Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a Jboss farm, load balanced by Apache HTTP + mod_proxy_balancer and mod_proxy_ajp, with the following configuration :

<VirtualHost *:80>

    ServerName web-gui-acceptance.myorg.com
    ServerAlias web-gui-acceptance


    ProxyRequests Off
    ProxyPass /web-gui balancer://jbosscluster/web-gui stickysession=JSESSIONID nofailover=On
    ProxyPassReverse /web-gui http://srvlnx01.myorg.com:8080/web-gui
    ProxyPassReverse /web-gui http://srvlnx02.myorg.com:8080/web-gui

    <Proxy *>
      AuthType Kerberos
      [...]
    </Proxy>

    <Proxy balancer://jbosscluster>
        BalancerMember ajp://srvlnx01.myorg.com:8009 route=SRVLNX01_node1
        BalancerMember ajp://srvlnx01.myorg.com:8009 route=SRVLNX02_node1
        ProxySet lbmethod=byrequests
    </Proxy>

</VirtualHost>

When the first JBoss node fail (the hosting VM is down), my existing connexions don't fail over the second node ... the fist route is keeped (in table / .shm ?) and that provide me 503 errors.

Can someone tell me what I missed ?

share|improve this question

1 Answer 1

up vote 0 down vote accepted

I may have found a workaround, that also deal with deployement / undeployement : http://www.jboss.org/mod_cluster

Advantages

mod_cluster boasts the following advantages over other httpd-based load balancers:

Dynamic configuration of httpd workers

Traditional httpd-based load balancers require explicit configuration of the workers available to a proxy. In mod_cluster, the bulk of the proxy's configuration resides on the application servers. The set of proxies to which an application server will communicate is determined either by a static list or using dynamic discovery via the advertise mechanism. The application server relays lifecycle events (e.g. server startup/shutdown) to the proxies allowing them to effectively auto-configure themselves. Notably, the graceful shutdown of a server will not result in a failover response by a proxy, as is the case with traditional httpd-based load balancers.

Server-side load balance factor calculation

In contrast with traditional httpd-based load balancers, mod_cluster uses load balance factors calculated and provided by the application servers, rather than computing these in the proxy. Consequently, mod_cluster offers a more robust and accurate set of load metrics than is available from the proxy. (see Load Metrics for more)

Fine grained web-app lifecycle control

Traditional httpd-based load balancers do not handle web application undeployments particularly well. From the proxy's perspective requests to an undeployed web application are indistinguishable from a request for an non-existent resource, and will result in 404 errors. In mod_cluster, each server forwards any web application context lifecycle events (e.g. web-app deploy/undeploy) to the proxy informing it to start/stop routing requests for a given context to that server.

AJP is optional

Unlike mod_jk, mod_cluster does not require AJP. httpd connections to application server nodes can use HTTP, HTTPS, or AJP. The original concepts are described in a wiki.

I hope that will help.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.