Hi, Camed across a strange thing today. A customer said his reverse proxied website was not working over https. After some troubleshooting I found this: [Fri Jun 08 08:18:40 2012] [error] proxy: BALANCER: (balancer://idm). All workers are in error state [Fri Jun 08 08:19:38 2012] [error] proxy: BALANCER: (balancer://idm). All workers are in error state <Proxy balancer://iam> Order deny,allow Allow from all BalancerMember http://xxx.xxx.xx.xx:8080/iam route=worker0 BalancerMember http://xxx.xxx.xx.xx:8080/iam route=worker1 </Proxy> ProxyPass /iam balancer://idm stickysession=JSESSIONID ProxyPassReverse /iam balancer://idm Should be: ProxyPass /iam balancer://iam stickysession=JSESSIONID ProxyPassReverse /iam balancer://iam So it seems like when you write a name of a balancer member which isn't defined, it's not checked when verifying the config. It starts up with no errors. But when accessing it, it gererates 503s. Best regards, Peter
Hi use <Proxy balancer://idm> and it should work better ;-) from my personal experience, my advice is to use the <Proxy> object as a pure substitution for {protocol://host:port}, and nothing more. <Proxy balancer://foo> # do not add a trailing '/' after IP:PORT (do not add a path, too) BalancerMember http://127.0.0.1:1234 BalancerMember http://127.0.0.1:2345 </Proxy> this view allows to clarify the substitution which is made by mod_proxy_balancer, by keeping equivalent things together: - level: substitute protocol://host:port (balancer's job) * balancer://foo ---> http://127.0.0.1:1234 - level: substitute request path (ProxyPass' job) * balancer://foo/path1 --> http://127.0.0.1:1234/path2 I found this logic to be a safe method to avoid the famous "double /" side-effect that you get when you want to "ProxyPass /"... eric
I don't understand your answer I am afraid. I still find this to be an issue. Their should be an inbuilt mechanism checking that the balancermember exits. /Peter
(In reply to comment #2) > I don't understand your answer I am afraid. > > I still find this to be an issue. Their should be an inbuilt mechanism > checking that the balancermember exits. > /Peter Hi My answer was only about the path appended to the 'scheme:/host:port/' declaration of your BalancerMembers (my experience says a BalancerMember should be seen as a "pure" host definition, and that the optional backend path should be declared in the ProxyPass/ProxyPassReverse lines) Anyway, I understand your point. Indeed, using a non-existent Proxy or using a Proxy which has zero BalancerMember has the same '503' effect, because this information is a pure run-time evaluation made by lbmethod providers (it is not their role to detect a wrong setup) This happens because the object is transparently created when the 'ProxyPass' directive is evaluated (it is probably made in order to allow a forward declaration of the balancer itself): (mod_proxy.c) ((( proxy_balancer *balancer = ap_proxy_get_balancer(cmd->pool, conf, r); if (!balancer) { const char *err = ap_proxy_add_balancer(&balancer, cmd->pool, conf, r); ))) Maybe a coherence check in the post_config hook could validate that there is no 'balancer://' object with zero elements ? (I can /try/ to make it...) eric
What would be great Eric! /Peter