11 Replies Latest reply: Mar 31, 2014 11:02 AM by Michal Babacek RSS

stickysession and ProxyPass problem?

Yves Peter Newbie

Hi

 

Stickysession doesn't work if there is a ProxyPass directive with a balancer that doesn't exist. Also on an apache with a lot of JBoss Servers connected to it via mod_cluster stickysession doesn't work at all.

I'm using mod_cluster 1.2. This used to work in  1.1.0.

Example:

 

LoadModule proxy_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy.so
LoadModule proxy_ajp_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_ajp.so
LoadModule proxy_cluster_module /opt/jboss/httpd/lib/httpd/modules/mod_proxy_cluster.so
LoadModule manager_module /opt/jboss/httpd/lib/httpd/modules/mod_manager.so
LoadModule slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_slotmem.so
LoadModule authn_default_module /opt/jboss/httpd/lib/httpd/modules/mod_authn_default.so
LoadModule authz_host_module /opt/jboss/httpd/lib/httpd/modules/mod_authz_host.so
LoadModule ssl_module /opt/jboss/httpd/lib/httpd/modules/mod_ssl.so

#Proxy information for ActiveVOS
ProxyPass /blabla_2 balancer://doesnotexist/blabla stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /blabla_2 balancer://doesnotexist/blabla

User apache
Group apache

Listen 10.32.34.116:80
Listen 10.32.34.116:443

ServerRoot "/data/jboss/httpd/jsplb01test"
DocumentRoot "/opt/jboss/httpd/htdocs/htdocs"

Timeout 300
KeepAlive On
KeepAliveTimeout 60
MaxKeepAliveRequests 0

ManagerBalancerName mycluster

#mod_cluster
#Maxnode 200
#Maxcontext 400
#AllowCmd Off
#UseAlias 0


<VirtualHost 10.32.34.116:80>
 EnableMCPMReceive
   <Directory />
      Order deny,allow
      Allow from all
   </Directory>

</VirtualHost>


<Location /mod_cluster-manager>
  SetHandler mod_cluster-manager
</Location>

 

All nodes use stickySession Force because session replication is off. Dump output of mod_cluster-manager:

balancer: [1] Name: vertragsverlauf Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 1 Timeout: 0 maxAttempts: 1
node: [1:1],Balancer: vertragsverlauf,JVMRoute: vertragsverlauf_z_02,LBGroup: [],Host: 10.32.34.70,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 26,ttl: 60,timeout: 0
node: [2:2],Balancer: vertragsverlauf,JVMRoute: vertragsverlauf_z_01,LBGroup: [],Host: 10.32.34.116,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 26,ttl: 60,timeout: 0
host: 1 [localhost] vhost: 1 node: 1
host: 2 [localhost] vhost: 1 node: 2
context: 1 [/lossratio_z] vhost: 1 node: 1 status: 1
context: 2 [/lossratio_webservice_z] vhost: 1 node: 1 status: 1
context: 3 [/claim_webservice_z] vhost: 1 node: 1 status: 1
context: 4 [/lossratio_z] vhost: 1 node: 2 status: 1
context: 5 [/lossratio_webservice_z] vhost: 1 node: 2 status: 1
context: 6 [/claim_webservice_z] vhost: 1 node: 2 status: 1

 

The proxypass is used to be able to distinguish different applications that have the same context root.

  • 1. Re: stickysession and ProxyPass problem?
    Jean-Frederic Clere Master

    hm I don' t understand what is wrong, could you explain what you are trying to do?

  • 2. Re: stickysession and ProxyPass problem?
    Yves Peter Newbie

    Ok. In the configuration above, there's a Web-GUI application running under the context /lossration_z which needs sticky session to work because the application isn't clustered (no session replication). Sticky session force is on. Without any proxypass directives in httpd.conf everything works fine but if I add the proxypass configuration (like what I posted above), sticky session for /lossration_z stops working. The balancer and context used in the proxypass isn't registered on the server and doesn't exist.

    Now, why would I need a proxypass directive to point to something that doesn't exists? Because I think this is related to a similar problem that I have: on a httpd with a lot of servers/context roots registered sticky session won't work either even thought there's no proxypass directive in the configuration. I just noticed the proxypass problem while trying to debug this and I think they are somehow related. Also in 1.1.3 it didn't mater if the proxypass directive pointed to something that existed or not.

     

    The end goal of this configuration is this:

    I have multiple application that have the same context root (/activevos) but should not be loadbalanced. Each application has it's own balancer like this:

    (balancer/contextroot)

    balancer://avos_appA/activevos

    balancer://avos_appB/activevos

     

    To be able to distinguish them I added a proxypass directive like this:

    ProxyPass /activevos_appA balancer://avos_appA/activevos stickysession=JSESSIONID|jsessionid nofailover=On
    ProxyPassReverse /activevos_appA balancer://avos_appA/activevos

     

    ProxyPass /activevos_appB balancer://avos_appB/activevos stickysession=JSESSIONID|jsessionid nofailover=On

    ProxyPassReverse /activevos_appB balancer://avos_appB/activevos

     

    Because we have different environments for staging I use the same configuration everywhere, even though the proxypass directives are not needed. It's just for convenience.

  • 3. Re: stickysession and ProxyPass problem?
    Jean-Frederic Clere Master

    It seems you try to work around something by additing ProxyPass directives in fact there was a bug (MODCLUSTER-274) it was fixed in 1.2.0.

    We should look to the "on a httpd with a lot of servers/context roots registered sticky session won't work either even thought there's no proxypass directive in the configuration.".

    Could you describe that problem? Sticky sessions do work do you get a fail-over or 503?

  • 4. Re: stickysession and ProxyPass problem?
    Yves Peter Newbie

    ProxyPass it self works (unlike in MODCLUSTER-274), sticky session for other contexts stops working if I try using it.

    Jean-Frederic Clere wrote:

    Could you describe that problem? Sticky sessions do work do you get a fail-over or 503?

    I get nothing, only 200 and then an exception in the application because it can't find the session. If I look at the headers I can see that the cookie changes betwen requests. In http log I get no errors.

    Here the output from Tamper Date Firefox plugin after clicking the submit button on a web form twice:

     

    13:36:04.592[306ms][total 306ms] Status: 200[OK]

    POST https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow Load Flags[LOAD_BYPASS_CACHE  LOAD_BACKGROUND  ] Content Size[3056] Mime Type[text/xml]

       Request Headers:

          Host[jsplb01z.uyellow.yellowcorp.test]

          User-Agent[Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0]

          Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]

          Accept-Language[en-us,en;q=0.5]

          Accept-Encoding[gzip, deflate]

          Connection[keep-alive]

          Content-Type[application/x-www-form-urlencoded; charset=UTF-8]

          Referer[https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow]

          Content-Length[708]

          Cookie[JSESSIONID=F2E805E5BD30955710EE6E2F39907175.vertragsverlauf_z_02]

          Pragma[no-cache]

          Cache-Control[no-cache]

       Post Data:

          AJAXREQUEST[criteriaForm%3Acriteria]

          criteriaForm[criteriaForm]

          criteriaForm%3AcriteriaTogglePanel[true]

          criteriaForm%3Aj_id23[]

          criteriaForm%3Aj_id26[]

          criteriaForm%3Aj_id29[]

          criteriaForm%3AobservationPeriodRadio[5]

          criteriaForm%3AobservationPeriodChosenStartCalendarInputDate[23.05.2007]

          criteriaForm%3AobservationPeriodChosenStartCalendarInputCurrentDate[05%2F2007]

          criteriaForm%3AchosenObservationPeriodEndCalendarInputDate[22.05.2012]

          criteriaForm%3AchosenObservationPeriodEndCalendarInputCurrentDate[05%2F2012]

          criteriaForm%3AreportingDateInputDate[23.05.2012]

          criteriaForm%3AreportingDateInputCurrentDate[05%2F2012]

          criteriaForm%3Aj_id48[on]

          javax.faces.ViewState[j_id2]

          criteriaForm%3Asubmit[criteriaForm%3Asubmit]

          []

       Response Headers:

          Date[Tue, 10 Apr 2012 11:36:04 GMT]

          Ajax-Response[true]

          Cache-Control[no-cache, must-revalidate, max_age=0, no-store]

          Expires[0]

          Pragma[no-cache]

          Content-Type[text/xml;charset=UTF-8]

          Vary[Accept-Encoding]

          Content-Encoding[gzip]

          Content-Length[3056]

          Keep-Alive[timeout=10]

          Connection[Keep-Alive]

     

    13:36:04.914[21ms][total 21ms] Status: 304[Not Modified]

    GET https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/a4j/g/3_3_2.SR1org.richfaces.renderkit.html.iconimages.DisabledCalendarIcon/DATB/eAFjYJjAOeU%21AASIAi0_.yellow Load Flags[LOAD_NORMAL] Content Size[-1] Mime Type[application/x-unknown-content-type]

       Request Headers:

          Host[jsplb01z.uyellow.yellowcorp.test]

          User-Agent[Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0]

          Accept[image/png,image/*;q=0.8,*/*;q=0.5]

          Accept-Language[en-us,en;q=0.5]

          Accept-Encoding[gzip, deflate]

          Connection[keep-alive]

          Referer[https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow]

          Cookie[JSESSIONID=F2E805E5BD30955710EE6E2F39907175.vertragsverlauf_z_02]

          If-Modified-Since[Sun, 20 May 2012 08:16:02 GMT]

       Response Headers:

          Date[Tue, 10 Apr 2012 11:36:04 GMT]

          Connection[Keep-Alive]

          Keep-Alive[timeout=10]

          Expires[Thu, 01 Jan 1970 01:00:00 CET]

          Cache-Control[no-cache]

     

    13:36:04.915[21ms][total 21ms] Status: 304[Not Modified]

    GET https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/a4j/g/3_3_2.SR1org.richfaces.renderkit.html.iconimages.CalendarIcon/DATB/eAFjYJjAOeU%21AASIAi0_.yellow Load Flags[LOAD_NORMAL] Content Size[-1] Mime Type[application/x-unknown-content-type]

       Request Headers:

          Host[jsplb01z.uyellow.yellowcorp.test]

          User-Agent[Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0]

          Accept[image/png,image/*;q=0.8,*/*;q=0.5]

          Accept-Language[en-us,en;q=0.5]

          Accept-Encoding[gzip, deflate]

          Connection[keep-alive]

          Referer[https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow]

          Cookie[JSESSIONID=F2E805E5BD30955710EE6E2F39907175.vertragsverlauf_z_02]

          If-Modified-Since[Sun, 20 May 2012 08:16:02 GMT]

       Response Headers:

          Date[Tue, 10 Apr 2012 11:36:04 GMT]

          Connection[Keep-Alive]

          Keep-Alive[timeout=10]

          Expires[Thu, 01 Jan 1970 01:00:00 CET]

          Cache-Control[no-cache]

     

    13:36:05.861[39ms][total 39ms] Status: 500[Internal Server Error]

    POST https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow Load Flags[LOAD_BYPASS_CACHE  LOAD_BACKGROUND  ] Content Size[-1] Mime Type[text/html]

       Request Headers:

          Host[jsplb01z.uyellow.yellowcorp.test]

          User-Agent[Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0]

          Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]

          Accept-Language[en-us,en;q=0.5]

          Accept-Encoding[gzip, deflate]

          Connection[keep-alive]

          Content-Type[application/x-www-form-urlencoded; charset=UTF-8]

          Referer[https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow]

          Content-Length[708]

          Cookie[JSESSIONID=F2E805E5BD30955710EE6E2F39907175.vertragsverlauf_z_02]

          Pragma[no-cache]

          Cache-Control[no-cache]

       Post Data:

          AJAXREQUEST[criteriaForm%3Acriteria]

          criteriaForm[criteriaForm]

          criteriaForm%3AcriteriaTogglePanel[true]

          criteriaForm%3Aj_id23[]

          criteriaForm%3Aj_id26[]

          criteriaForm%3Aj_id29[]

          criteriaForm%3AobservationPeriodRadio[5]

          criteriaForm%3AobservationPeriodChosenStartCalendarInputDate[23.05.2007]

          criteriaForm%3AobservationPeriodChosenStartCalendarInputCurrentDate[05%2F2007]

          criteriaForm%3AchosenObservationPeriodEndCalendarInputDate[22.05.2012]

          criteriaForm%3AchosenObservationPeriodEndCalendarInputCurrentDate[05%2F2012]

          criteriaForm%3AreportingDateInputDate[23.05.2012]

          criteriaForm%3AreportingDateInputCurrentDate[05%2F2012]

          criteriaForm%3Aj_id48[on]

          javax.faces.ViewState[j_id2]

          criteriaForm%3Asubmit[criteriaForm%3Asubmit]

          []

       Response Headers:

          Date[Tue, 10 Apr 2012 11:36:05 GMT]

          Set-Cookie[JSESSIONID=7A3EFC3CC8E5C209BA9E2B64AA79257B.vertragsverlauf_z_01; Path=/lossratio_z; Secure]

          Content-Type[text/html;charset=UTF-8]

          Vary[Accept-Encoding]

          Content-Encoding[gzip]

          Connection[close]

          Transfer-Encoding[chunked]

     

    13:36:05.920[42ms][total 42ms] Status: 200[OK]

    GET https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/resources/images/yellow_logo.png Load Flags[LOAD_NORMAL] Content Size[15139] Mime Type[image/png]

       Request Headers:

          Host[jsplb01z.uyellow.yellowcorp.test]

          User-Agent[Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0]

          Accept[image/png,image/*;q=0.8,*/*;q=0.5]

          Accept-Language[en-us,en;q=0.5]

          Accept-Encoding[gzip, deflate]

          Connection[keep-alive]

          Referer[https://jsplb01z.uyellow.yellowcorp.test/lossratio_z/pages/lossratio.yellow]

          Cookie[JSESSIONID=7A3EFC3CC8E5C209BA9E2B64AA79257B.vertragsverlauf_z_01]

          If-Modified-Since[Wed, 18 Jan 2012 19:06:10 GMT]

          If-None-Match[W/"15139-1326913570000"]

       Response Headers:

          Date[Tue, 10 Apr 2012 11:36:05 GMT]

          Pragma[No-cache]

          Cache-Control[no-cache]

          Expires[Thu, 01 Jan 1970 01:00:00 CET]

          Accept-Ranges[bytes]

          Etag[W/"15139-1301322364000"]

          Last-Modified[Mon, 28 Mar 2011 14:26:04 GMT]

          Content-Type[image/png]

          Content-Length[15139]

          Keep-Alive[timeout=10]

          Connection[Keep-Alive]

  • 5. Re: stickysession and ProxyPass problem?
    Jean-Frederic Clere Master

    Sorry I still don't get it:

    - without any ProxyPass mod_cluster works correctly.

    - once additing a ProxyPass it stops working: the session aren't sticky.

    Is that correct? what is the minimal ProxyPass directive that causes the problem.

    Would it be possible to increase the httpd log level to debug and send me the corresponding error_log file?

  • 6. Re: stickysession and ProxyPass problem?
    Yves Peter Newbie

    Yes that's correct. I have another problem with sticky session where there's no ProxyPass involved but let's ignore that for now.

    I attached the minimal configuration and the Apache error_log. It seams as if the ProxyPass directive deactivates StickySession completely.

  • 7. Re: stickysession and ProxyPass problem?
    Jean-Frederic Clere Master

    I have reproduced the problem you should create a JIRA, the work-around is to remove the ProxyPass.

  • 8. Re: stickysession and ProxyPass problem?
    inspector Newbie

    I'm sorry for digging out this thread, but I'm experiencing an issue which might be related to the one explained here.

     

    mod_cluster does not respect LoadBalancingGroups anymore when I use a ProxyPass directive, it simply balances over all available nodes ignoring their load-balancing-groups. And as already stated above, the sticky-session attribute (which is true by default as far as I know) is ignored too.

     

    I am using the configuration shown below with the cluster-example from here as deployed application. I have two LoadBalancingGroups with only one member each (minimal example). The two JBosses are started with the standalone-ha.xml but use different multicast addresses so they do not form a cluster.

    EDIT Sorry, I forgot the version numbers: I'm using mod_cluster 1.2.0.Final in combination with JBoss AS 7.1.2.Final.

     

    apache side:

     

    Listen 192.168.122.165:10001
    CreateBalancers 0
    
    <VirtualHost 192.168.122.165:10001>
    
      KeepAliveTimeout 60
      MaxKeepAliveRequests 0
    
      ManagerBalancerName ModClusterNode1
    
      ProxyPass / balancer://ModClusterNode1/ stickysession=JSESSIONID|jsessionid nofailover=On
      ProxyPassReverse / balancer//ModClusterNode1/
    
      ServerAdvertise On
      AdvertiseGroup 224.0.1.105:23364
      AdvertiseFrequency 5
      EnableMCPMReceive
    
      <Location />
        Order deny,allow
        Allow from all
      </Location>
    
      <Location /mod_cluster-manager>
       SetHandler mod_cluster-manager
       Order deny,allow
       Allow from all
    #   Deny from all
      </Location>
    </VirtualHost>
    

     

    BTW: The parameters to ProxyPass (i.e. stickysession and nofailover) do not seem to have the balancer simply balances over both LoadBalancingGroups

     

    and the JBoss side:

     

            <subsystem xmlns="urn:jboss:domain:modcluster:1.1">
                <mod-cluster-config advertise-socket="modcluster" connector="ajp" load-balancing-group="LB1">
                    <dynamic-load-provider>
                        <load-metric type="busyness"/>
                    </dynamic-load-provider>
                </mod-cluster-config>
            </subsystem>
    

    and respectively

     

            <subsystem xmlns="urn:jboss:domain:modcluster:1.1">
                <mod-cluster-config advertise-socket="modcluster" connector="ajp" load-balancing-group="LB2">
                    <dynamic-load-provider>
                        <load-metric type="busyness"/>
                    </dynamic-load-provider>
                </mod-cluster-config>
            </subsystem>
    
  • 9. Re: stickysession and ProxyPass problem?
    Jean-Frederic Clere Master

    Remove the ProxyPass directives and it will work.

  • 10. Re: stickysession and ProxyPass problem?
    Jan Hugo Prins Newbie

    Hello,

     

    Do you have any idea if this problem has been fixed in some mod_cluster release?

    We are currently testing version 1.2.6 and it looks like the problem is still in this release.

     

    Jan Hugo Prins