fredk2 schrieb:
Hi,

when you set a load balancer (mod_jk v1.2.26) with 2 workers:
    worker.myWorker.type=lb
    worker.myWorker.balance_workers=tc1Worker, tc2Worker

and one of the worker's host cannot be resolved:
    worker.tc2Worker.host=mytest.mydom.com

Then Apache will not start.

- since the other worker is 'good', should'nt we let apache start with a
nice error message informing you that one worker could not resolved (done
today) and jk will disable the worker and let apache start anyway?

- Adding a disable does not fix the issue it seems.  Only removing the
worker from the list does.
    worker.tc2Worker.activation=d

Yes that's the way it was implemented intentionally.

The idea is that if DNS fails to resolve a host (some admin mistake) and
Apache was restarted automatically for unrelated reasons, it would fail to
come back online without a manual intervention - editing a configuration
file (which might be a challenge).

In general I think it's better to not start, if a worker is completely broken. Yes, in your case it would provide a problem with regular restarts, but we could argue, that if your DNS is not rock solid, but your production systems depend on IP address resolution, then you should either use the IPs in the workers host attribute, or add the few systems you need to contact from your httpd to your hosts file. Of course that contradicts the major goals of DNS, but if you want to stick to those you really need a rock solid DNS (which is not that hard). Admin failures when managing critical DNS data are really major incidents.

If we allow unresolvable host names, it's very likely that users will not notice the resulting error messages during startup. And I think it's much more likely that people simply put typos into the host names than the occurence of local DNS failures.

This seems to be grey area, where there's no obviously best solution.

Rgds - Fred

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to