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 <Location>, <Directory> or <Proxy> 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 <Location> content at a different time (in the HTTP request cycle) compared to what is contained in <Directory> sections (and thus probably also <Proxy> 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 <Proxy> 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 <Proxy> 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 <Proxy> block comes first (before the ProxyPass), then it is the <Proxy> 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 <Proxy> block, then it is the ProxyPass which creates the worker (and the attributes are not ignored). And when the <Proxy> 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 <Proxy> 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 <Proxy> 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:

<Proxy "balancer://myapp">
   BalancerMember https://tomcat-1/ route=tc1
   BalancerMember https://tomcat-2/ route=tc2
</Proxy>

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:

<Proxy "balancer://myapp">
   BalancerMember https://tomcat-1/ route=tc1
   BalancerMember https://tomcat-2/ route=tc2
   ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
</Proxy>

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



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

Reply via email to