André,
On 12/22/21 16:14, André Warnier (tomcat/perl) wrote:
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).
Haha, sorry.
The behavior is (confirmed by logging all probalancer-related
environment variables) that the balancer always chooses "-" for
$BALANCER_SESSION_ROUTE. Moving the stickiness directive into the
<Proxy> as ProxySet gets it working such that BALANCER_SESSION_ROUTE is
one of tc1 or tc2 when the client sends an appropriate session cookie
(generated by Tomcat).
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.
What about "section-less" directives like ProxyPass where the direct
parent is <VirtualHost>? That's what I have in my example: no
<Location>, no <Directory>, etc.
I *do* have one of these:
ProxyPass [stuff] [proxystuff] !
That is: DO NOT PROXY a URL like [stuff]. I didn't bother to add the
stickness parameter to that ProxyPass directive since I figured "I'm not
proxying, stickiness doesn't matter." I may have been wrong.
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)
Aha! I think this does explain what's happening. I mostly read the
mod_proxy_balancer page and not too much from the mod_proxy page where
this is all discussed. I should have read more :)
- 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).
That would be an interesting experiment. I surely like the <Proxy>
declaration coming first better than the reverse: using a balancer
"before" it has been declared seems (a) wrong and (b) confusing to read.
If I had this:
ProxyPass [stuff] [proxystuff] timeout=60
<Proxy [proxystuff]>
ProxySet timeout=10
</Proxy>
Would the timeout be 60 or 10? Sounds like it would be 60 because "the
first one wins." That behavior is *very* surprising, as I expect the
"most specific" configuration to override the least-specific, but that's
because I'm not used to httpd's (rather consistent, I might add) "first
declaration wins" behavior.
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.
:D
Thanks for that analysis, it makes a lot of sense. I also feel like I'm
not completely crazy because there is a plausible explanation, even if
it wasn't what I had expected. As usual, human expectations don't
control software systems: it is the humans who have to follow the
software's rules, not the other way around.
-chris
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
