Re: Session stickiness with mod_proxy_balancer

2021-12-22 Thread tomcat/perl

Hi Chris.
Maybe the problem was due to this :
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
the snippet after "Mixing ProxyPass settings in different contexts does not 
work:"
In your first configuration below, the ProxyPass (including the settings of the variables) 
is outside of any ,  or  block, while the other proxy-related 
directives are inside a block; those are 2 different "contexts".
(And clearly, the "does not work" could have been a bit more explicit; as it is, it sounds 
like my customers reporting issues).


Alternatively, the difference between the 2 configurations may be due to a question of 
priority (or "overriding"). Apache httpd considers  content at a different time 
(in the HTTP request cycle) compared to what is contained in  sections (and 
thus probably also  sections), and compared to what is not contained in any section 
(and which is thus considered as "VirtualHost-level"). Within each section, the 
interpretation is generally top-down.


In your 1st configuration below, I notice that the ProxyPass directive is *after* the 
 block, while in the example at

https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#balancer_manager
, the ProxyPass directive *precedes* the  block.

That may sound insignificant or finicky as a difference,
but actually, based on 
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#workers,
this second explanation may be the right one :
If I understand that page correctly,

- if your  block comes first (before the ProxyPass), then it is the  block 
which creates the "balancer:" worker. And then, when the ProxyPass is evaluated, not only 
does it "re-use" that same worker, but also the attributes of the ProxyPass are ignored.
(quote: "Note that all configuration attributes given explicitly for the later worker will 
be ignored")(It also says "This will be logged as a warning", so if you still have access 
to the old log, you could check)


- while if the ProxyPass directive comes before the  block, then it is the 
ProxyPass which creates the worker (and the attributes are not ignored). And when the 
 is evaluated, it "re-uses" the worker created by ProxyPass (with its 
already-defined attributes).


The same logic also explains why your 2d configuration does work :
- the  block creates the "balancer" worker AND sets its attributes via 
ProxySet
- the ProxyPass directive comes after, and it re-uses the "balancer" worker, but it does 
not set parameters (which would be ignored anyway, with a warning logged)


This could be easily confirmed (or negated) if you had a chance to restore your first 
configuration, and just moved the ProxyPass above the  block.

(But in the end, I believe that your 2d configuration is more "solid" anyway).

In the end, each httpd add-on module (like mod_proxy and mod_proxy_balancer) is 
responsible for its own interpretation (and ordering) of the directives that relate to it, 
and they are not always totally consistent with one another in that respect.


For even more sordid details, see 
https://httpd.apache.org/docs/2.4/sections.html
and its sections :
- How the sections are merged
and
- Relationship between modules and configuration sections

and if after that you really understand what is going on, come back to me to explain, 
because after 20+ years of configuring Apache httpd, I'm still not sure sometimes.


On 22.12.2021 18:04, Christopher Schultz wrote:

All,

I'm setting up mod_proxy_balancer to talk to Tomcat after having only used mod_jk for a 
very long time. With a multiple-Tomcat-node situation, I was finding that sessions didn't 
seem to be "sticking" and I thought I had my configuration correct. Something like this:



   BalancerMember https://tomcat-1/ route=tc1
   BalancerMember https://tomcat-2/ route=tc2


ProxyPass /myapp/ balancer://myapp/ stickysession=JSESSIONID|jsessionid 
scolonpathdelim=On
ProxyPassReverse /myapp/ balancer://myapp/

I found that httpd wasn't picking-up my session ids from JSESSIONID cookies like 
76234132976549238.tc1 or 642586735782.tc2.


However, when I *moved* the configuration from the ProxyPass line into the balancer 
configuration like this, it works as expected:



   BalancerMember https://tomcat-1/ route=tc1
   BalancerMember https://tomcat-2/ route=tc2
   ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On


ProxyPass /myapp/ balancer://myapp/
ProxyPassReverse /myapp/ balancer://myapp/

Was I incorrect in my expectations? I would expect that the two configurations would work 
the same way.


This is a client system so I can't really play around with it too much at this point. Once 
it started working, we stopped messing-around with it. I can probably create another 
similar setup but it will take me a while to do so; if anyone can explain what I'm seeing 
without me having to reproduce it, that would be great ;)


-chris

-
To unsubscribe, e-mail: 

Session stickiness with mod_proxy_balancer

2021-12-22 Thread Christopher Schultz

All,

I'm setting up mod_proxy_balancer to talk to Tomcat after having only 
used mod_jk for a very long time. With a multiple-Tomcat-node situation, 
I was finding that sessions didn't seem to be "sticking" and I thought I 
had my configuration correct. Something like this:



  BalancerMember https://tomcat-1/ route=tc1
  BalancerMember https://tomcat-2/ route=tc2


ProxyPass /myapp/ balancer://myapp/ stickysession=JSESSIONID|jsessionid 
scolonpathdelim=On

ProxyPassReverse /myapp/ balancer://myapp/

I found that httpd wasn't picking-up my session ids from JSESSIONID 
cookies like 76234132976549238.tc1 or 642586735782.tc2.


However, when I *moved* the configuration from the ProxyPass line into 
the balancer configuration like this, it works as expected:



  BalancerMember https://tomcat-1/ route=tc1
  BalancerMember https://tomcat-2/ route=tc2
  ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On


ProxyPass /myapp/ balancer://myapp/
ProxyPassReverse /myapp/ balancer://myapp/

Was I incorrect in my expectations? I would expect that the two 
configurations would work the same way.


This is a client system so I can't really play around with it too much 
at this point. Once it started working, we stopped messing-around with 
it. I can probably create another similar setup but it will take me a 
while to do so; if anyone can explain what I'm seeing without me having 
to reproduce it, that would be great ;)


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org