Re: Session stickiness with mod_proxy_balancer
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 , 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). 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 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 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. What about "section-less" directives like ProxyPass where the direct parent is ? That's what I have in my example: no , no , 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 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) 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 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). That would be an interesting experiment. I surely like the 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 ProxySet timeout=10 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 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
Re: Session stickiness with mod_proxy_balancer
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:
