tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark H. Wood" <mw...@IUPUI.Edu>
Subject Re: Server.xml Sort on Start
Date Thu, 24 May 2007 13:08:33 GMT
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

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   mwood@IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

View raw message