I don't *know*, mind you, but random ordering suggests that the container starts a thread for each 'host' and the checks are taking place in those threads. Thread switching is influenced by lots of things and would be fairly unpredictable, so a bunch of threads setting up host objects could complete or fail in any order.
The code knows for sure, and you can inspect it if you wish. I'm hoping that someone who has already done so will step forward with, "Mark's right," or, "he's talking rot, you know, it's really thusandso." But it makes a certain amount of sense to spin off a thread to manage each address:port pair and let those threads take care of checking and setup for their own areas of responsibility. If my guess is right, then you're kind of stuck with your current method of debugging the config., but maybe you can automate it. It mightn't be too hard to script up something that processes the log and makes a list of which app.s *did* start. server.xml is, well, XML, so there are plenty of good tools that can be used to edit it programmatically. For example, move all of the known working 'host' declarations to the end and start again, perhaps shuffling the remainder. You could automatically loop through this until the bad'un is isolated. This sort of thing would be a waste of programming time for a handful of hosts, but if you have scores of them and they are fairly volatile then automated "Monte Carlo debugging" (if you will) may be a good approach. Another method would be to disable automatic deployment at startup, and then drive the manager app. with a script that starts each app. until one fails or Tomcat freezes. Less fun, more determinism. Yet another tactic would be to keep the Tomcat config. files in a revision control system, or at least to keep backups (possibly with your editor's help), so that you can readily zero in on the changes between a recent working config. and the busted one. If this is an ongoing problem then keeping good records of what went wrong each time might be useful. As you spot patterns, you may be able to develop antibugging techniques and tools to better avoid the common problems. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgp6j3MqFMdLN.pgp
Description: PGP signature
