Ruediger Pluem wrote:
- for (i = 0; i < arr->nelts; i++) {
- const char *err = set_balancer_param(conf, cmd->pool, balancer,
elts[i].key,
- elts[i].val);
+ else {
+ if (params->nelts > 0 &&
+ (balancer->sticky || balancer->sticky_force ||
+ balancer->max_attempts_set || balancer->timeout)) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server,
+ "repeated parameter definition for balancer %s "
+ "overwrites previous definitions",
+ balancer->name);
+ balancer->sticky = NULL;
Why resetting balancer->sticky here? It is not clear that the contents of
balancer->sticky is changed. It makes sense to reset it if we have at least
one "stickysession" parameter inside of params->elts so that we cleanly
overwrite all the "stickysession" stuff then.
What makes me a bit lost is the following configuration situation:
You declare a balancer:
<Proxy balancer://mycloud>
BalancerMember ajp://192.168.1.1:5001 route=member1
BalancerMember ajp://192.168.1.2:5001 route=member2
</Proxy>
Now I want to balance 2 paths:
<Location /app1>
ProxyPass balancer://mycloud/app1 stickysession=JSESSION
</Location>
<Location /app2>
ProxyPass balancer://mycloud/app2 stickysession=JSESSION
</Location>
The repeated ProxyPass definitions might give the impression that you
can specify
different settings for /app1 and /app2 - e.g. stickysession parameters
(which is not true).
Using an elegant:
<LocationMatch "/(app1|app2)">
is also not possible if the path element (/app1 vs /app2) has to be
passed to the backend.
I am missing an elegant solution for mapping multiple paths to the same
balancer.
Did I miss something here?
Best regards,
Georg
