You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kyle B <kb...@gmail.com> on 2007/05/24 03:10:27 UTC

Server.xml Sort on Start

I am inquiring about the algorithm Tomcat uses for processing the
server.xmlfile on startup.

When Tomcat is started, it processes all hosts listed in the server.xml file
for catalina policy compliance. Issues arise when there is an account that
does not comply with our policy file and Tomcat refuses to start up. 90% of
the time, it prints the host it is processing just prior to error. This
obviously allows us to disable that host, and Tomcat will start.

However, the other 10% of the time, it will print an error and not specify
the host it is processing that caused that error. Therefore, we are unable
to determine which host to disable.

This results in having to do a binary search on the server.xml, commenting
out large chunks of hosts until a single culprit is left. On this latter
10%, it will print the last successful host processed prior to the error...
but this does not help, as we can not determine the next host in succession.

I would assume that Tomcat processes the hosts on startup in the order they
lie in the server.xml file. However, that is not the case. They jump all
over the place. An example would be:

<Host name='domain.com'
 debug='0'
 appBase='/path/to/java/app'
 unpackWARs='true'
 autoDeploy='false'>
 <Alias>www.domain.com</Alias>
 <Context path='' docBase='' debug='0' reloadable='false'/>
 <Valve  className='org.apache.catalina.authenticator.SingleSignOn'
 debug='0'/>
 <Valve  className='org.apache.catalina.valves.AccessLogValve'
 directory=''
 prefix='tomcat_access.'
 suffix='.log'
 pattern='common'
 resolveHosts='false'/>
</Host>


We have a fair number of hosts on each java box. It neither sorts the
server.xml by alphabetic order, or file succession as it will skip from host
32, to 864, to 1026, to 127, etc... (jumping all over the place).

Can anyone explain the server.xml sorting algorithm Tomcat uses on start?

Regards,

-Kyle

RE: Server.xml Sort on Start

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Kyle B [mailto:kbinaz@gmail.com] 
> Subject: Server.xml Sort on Start
> 
> Can anyone explain the server.xml sorting algorithm Tomcat 
> uses on start?

Tomcat handles most configuration items by inserting them into a HashMap
and then iterating over the contents.  The resulting order should be
based on the hash index of whatever key is used; for <Host> elements,
that appears to be the name attribute.  I suppose you could run a simple
program that mimics the Tomcat mechanism to find the resulting order.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


RE: Server.xml Sort on Start

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Kyle B [mailto:kbinaz@gmail.com] 
> Subject: Re: Server.xml Sort on Start
> 
> The Host elements do not contain backgroundProcesserDelay. 

Not by default, but one can be added.  I wouldn't recommend it, since
there doesn't seem to be much advantage to do so unless one has many,
many <Host> elements and multiple CPUs.

> It's not sorted by element order in the server.xml, nor by 
> name attribute, or appBase.

As I stated before, the order appears to be that of the HashMap index of
the name attribute of the <Host> element.  This is not the simple
hashCode() of the name string, since the processing in HashMap does some
manipulation of the hashCode() result prior to inserting the item in the
map.  The processing in Tomcat converts the HashMap to an object array
prior to processing; this array is typically in HashMap index order,
although that's not defined by the JRE API spec and could change from
one JVM implementation or level to another.

You don't need to process XML to determine the processing order.  Just
take the list of <Host> names in the same order they appear in
server.xml, and run a simple program against the list to insert the
names into a HashMap, convert the Map to an object array, and see what
the order is.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


Re: Server.xml Sort on Start

Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Thu, May 24, 2007 at 07:37:25PM -0700, Kyle B wrote:
[snip]
> In regards to Mark's statement. I'm not opposed to writing some XML parsing
> tools to play nice with Tomcat. However, I'm still left trying to figure out
> how Tomcat sorts that HashMap it creates for all <Host> elements. I've
> looked for patterns that I just can't find. It's not sorted by element order
> in the server.xml, nor by name attribute, or appBase.

Given the information that hosts are collected in a HashMap: Tomcat
isn't sorting anything, and you can't sort a HashMap*.  Hashing
functions are designed to distribute a large key space over a much
smaller set of "buckets" in constant time.  The more apparently random
the relationship between input and output, the better for this
purpose, in most cases.  The entries in a hashtable are deliberately
DISordered on insertion.  Hashing data is like hashing meat and
potatoes: the result is expected to be finely divided and well mixed.

-------------------
* You could sort its content into some other data structure, but apparently
  that's not done here.

-- 
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.


Re: Server.xml Sort on Start

Posted by Kyle B <kb...@gmail.com>.
Charles,

The Host elements do not contain backgroundProcesserDelay. Here is a sample:

<Host name='domain.com'
 debug='0'
 appBase='/path/to/java/app'
 unpackWARs='true'
 autoDeploy='false'>
 <Alias>www.domain.com</Alias>
 <Context path='' docBase='' debug='0' reloadable='false'/>
 <Valve  className='org.apache.catalina.authenticator.SingleSignOn'
 debug='0'/>
 <Valve  className='org.apache.catalina.valves.AccessLogValve'
 directory=''
 prefix='tomcat_access.'
 suffix='.log'
 pattern='common'
 resolveHosts='false'/>
</Host>

In regards to Mark's statement. I'm not opposed to writing some XML parsing
tools to play nice with Tomcat. However, I'm still left trying to figure out
how Tomcat sorts that HashMap it creates for all <Host> elements. I've
looked for patterns that I just can't find. It's not sorted by element order
in the server.xml, nor by name attribute, or appBase.

I know it's not completely random as running the restart always yields the
results in the same order. But I just can't figure out said order.

Anyone else have any personal experience with figuring out the sorting
algorithm Tomcat uses on all <Hosts> in the server.xml on start?

Thanks for all the responses so far,

-Kyle



On 5/24/07, Caldarale, Charles R <Ch...@unisys.com> wrote:
>
> > From: Mark H. Wood,UL 0115A,+1 317 274 0749,
> > [mailto:mwood@mhw.ulib.iupui.edu] On Behalf Of Mark H. Wood
> > Subject: Re: Server.xml Sort on Start
> >
> > 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.
>
> Not by default - the <Host> entries are processed by the thread that
> handles the <Engine>.  However, setting backgroundProcesserDelay in a
> <Host> element will cause it to be processed by its own thread.  (It's
> default value is -1.)  Look at the Threads display in Lambda Probe for
> ContainerBackgroundProcessor threads.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Server.xml Sort on Start

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark H. Wood,UL 0115A,+1 317 274 0749, 
> [mailto:mwood@mhw.ulib.iupui.edu] On Behalf Of Mark H. Wood
> Subject: Re: Server.xml Sort on Start
> 
> 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.

Not by default - the <Host> entries are processed by the thread that
handles the <Engine>.  However, setting backgroundProcesserDelay in a
<Host> element will cause it to be processed by its own thread.  (It's
default value is -1.)  Look at the Threads display in Lambda Probe for
ContainerBackgroundProcessor threads.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

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


Re: Server.xml Sort on Start

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


Re: Server.xml Sort on Start

Posted by Kyle B <kb...@gmail.com>.
Martin,

Thank you for your response. However, the issue does not relate to certain
locations being denied access. The problem is that during Tomcat restart, it
processes all WEB-INF folders and comes back with output like:

----------
INFO: Create Host deployer for direct deployment ( non-jmx )
May 23 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
May 23 org.apache.catalina.startup.ContextConfig applicationConfig
INFO: Missing application web.xml, using defaults only
StandardEngine[hosting].StandardHost[domain24.com].StandardContext[]
May 23 org.apache.catalina.core.StandardHost getDeployer
INFO: Create Host deployer for direct deployment ( non-jmx )
May 23 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
May 23 org.apache.catalina.startup.ContextConfig applicationConfig
INFO: Missing application web.xml, using defaults only
StandardEngine[hosting].StandardHost[domain368.com].StandardContext[]
May 23 org.apache.catalina.core.StandardHost getDeployer
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422)
Caused by: java.lang.UnsupportedClassVersionError: Bad version number in
.class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(
WebappClassLoader.java:1634)
at org.apache.catalina.loader.WebappClassLoader.findClass(
WebappClassLoader.java:860)
at org.apache.catalina.loader.WebappClassLoader.loadClass(
WebappClassLoader.java:1307)
at org.apache.catalina.loader.WebappClassLoader.loadClass(
WebappClassLoader.java:1189)
at org.apache.catalina.core.StandardWrapper$1.run(StandardWrapper.java:947)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java
:943)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862)
at org.apache.catalina.core.StandardContext.loadOnStartup(
StandardContext.java:4013)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4357)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at org.apache.catalina.core.StandardService.start(StandardService.java:480)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
----------

In the server.xml file, the hosts are listed like:
<Host name='www.domain1.com'
....
/>
</Host>
<Host name='www.domain2.com'
....
/>
</Host>
etc...


But during startup, as you can see from the output, it jumps around from
domain24.com to domain368.com. It seems to pick the hosts at random during
Tomcat start. The issue that arises is that we can not determine the host
causing the error. You will get the success message for domain368.com, and
then it comes back with the class error and fails to start (because of the
next <Host> in line). The only way to get it to start is to disable the host
with that code that's causing issues. Right now we're disabling large chunks
of hosts in the server.xml file until we find the one responsible.

I'm trying to figure out how Tomcat sorts the server.xml file on start so
that I can just find the next host in line after domain368.com and save
myself 2 hours of disabling random accounts.

Regards,

-Kyle


On 5/23/07, Martin Gainty <mg...@hotmail.com> wrote:
>
> Kyle-
> someone probably put in a deny in your engine config in server.xml e.g.
> <Engine name="Catalina" defaultHost="localhost">
> //if you see a Valve declaration such as
> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>          deny="192.168.1.*"/>
> and replace deny with allow
> and you should be good for all the addresses which were previously denied
> HTH/
> Martin
> This email message and any files transmitted with it contain confidential
> information intended only for the person(s) to whom this email message is
> addressed.  If you have received this email message in error, please
> notify
> the sender immediately by telephone or email and destroy the original
> message without making a copy.  Thank you.
>
> ----- Original Message -----
> From: "Kyle B" <kb...@gmail.com>
> To: <us...@tomcat.apache.org>
> Sent: Wednesday, May 23, 2007 9:10 PM
> Subject: Server.xml Sort on Start
>
>
> >I am inquiring about the algorithm Tomcat uses for processing the
> > server.xmlfile on startup.
> >
> > When Tomcat is started, it processes all hosts listed in the server.xml
> > file
> > for catalina policy compliance. Issues arise when there is an account
> that
> > does not comply with our policy file and Tomcat refuses to start up. 90%
> > of
> > the time, it prints the host it is processing just prior to error. This
> > obviously allows us to disable that host, and Tomcat will start.
> >
> > However, the other 10% of the time, it will print an error and not
> specify
> > the host it is processing that caused that error. Therefore, we are
> unable
> > to determine which host to disable.
> >
> > This results in having to do a binary search on the server.xml,
> commenting
> > out large chunks of hosts until a single culprit is left. On this latter
> > 10%, it will print the last successful host processed prior to the
> > error...
> > but this does not help, as we can not determine the next host in
> > succession.
> >
> > I would assume that Tomcat processes the hosts on startup in the order
> > they
> > lie in the server.xml file. However, that is not the case. They jump all
> > over the place. An example would be:
> >
> > <Host name='domain.com'
> > debug='0'
> > appBase='/path/to/java/app'
> > unpackWARs='true'
> > autoDeploy='false'>
> > <Alias>www.domain.com</Alias>
> > <Context path='' docBase='' debug='0' reloadable='false'/>
> > <Valve  className='org.apache.catalina.authenticator.SingleSignOn'
> > debug='0'/>
> > <Valve  className='org.apache.catalina.valves.AccessLogValve'
> > directory=''
> > prefix='tomcat_access.'
> > suffix='.log'
> > pattern='common'
> > resolveHosts='false'/>
> > </Host>
> >
> >
> > We have a fair number of hosts on each java box. It neither sorts the
> > server.xml by alphabetic order, or file succession as it will skip from
> > host
> > 32, to 864, to 1026, to 127, etc... (jumping all over the place).
> >
> > Can anyone explain the server.xml sorting algorithm Tomcat uses on
> start?
> >
> > Regards,
> >
> > -Kyle
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Server.xml Sort on Start

Posted by Martin Gainty <mg...@hotmail.com>.
Kyle-
someone probably put in a deny in your engine config in server.xml e.g.
 <Engine name="Catalina" defaultHost="localhost">
//if you see a Valve declaration such as
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
         deny="192.168.1.*"/>
and replace deny with allow
and you should be good for all the addresses which were previously denied
HTH/
Martin
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.

----- Original Message ----- 
From: "Kyle B" <kb...@gmail.com>
To: <us...@tomcat.apache.org>
Sent: Wednesday, May 23, 2007 9:10 PM
Subject: Server.xml Sort on Start


>I am inquiring about the algorithm Tomcat uses for processing the
> server.xmlfile on startup.
>
> When Tomcat is started, it processes all hosts listed in the server.xml 
> file
> for catalina policy compliance. Issues arise when there is an account that
> does not comply with our policy file and Tomcat refuses to start up. 90% 
> of
> the time, it prints the host it is processing just prior to error. This
> obviously allows us to disable that host, and Tomcat will start.
>
> However, the other 10% of the time, it will print an error and not specify
> the host it is processing that caused that error. Therefore, we are unable
> to determine which host to disable.
>
> This results in having to do a binary search on the server.xml, commenting
> out large chunks of hosts until a single culprit is left. On this latter
> 10%, it will print the last successful host processed prior to the 
> error...
> but this does not help, as we can not determine the next host in 
> succession.
>
> I would assume that Tomcat processes the hosts on startup in the order 
> they
> lie in the server.xml file. However, that is not the case. They jump all
> over the place. An example would be:
>
> <Host name='domain.com'
> debug='0'
> appBase='/path/to/java/app'
> unpackWARs='true'
> autoDeploy='false'>
> <Alias>www.domain.com</Alias>
> <Context path='' docBase='' debug='0' reloadable='false'/>
> <Valve  className='org.apache.catalina.authenticator.SingleSignOn'
> debug='0'/>
> <Valve  className='org.apache.catalina.valves.AccessLogValve'
> directory=''
> prefix='tomcat_access.'
> suffix='.log'
> pattern='common'
> resolveHosts='false'/>
> </Host>
>
>
> We have a fair number of hosts on each java box. It neither sorts the
> server.xml by alphabetic order, or file succession as it will skip from 
> host
> 32, to 864, to 1026, to 127, etc... (jumping all over the place).
>
> Can anyone explain the server.xml sorting algorithm Tomcat uses on start?
>
> Regards,
>
> -Kyle
> 


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