tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric B." <>
Subject Re: How to manage Apache error msgs when Tomcat is down?
Date Wed, 12 Sep 2007 19:29:16 GMT
>> Thanks for the input.  I didn't build my own for 2 reasons: 1) don't
>> have any cc / gcc on my RHEL linux server  - it is used purely for
>> production and only have proven stable things on it from the RHEL
>> updates.
> Leaving gcc off your production service is a good idea, but I don't buy
> your "stability" argument. Red Hat certainly has a stable gcc available
> for their distro.

Agreed, but I find that gcc lends you to compile things yourself, which may 
be more "bleeding-edge" than you want.  By keeping gcc off the machine, it 
forces an admin to download only precompiled RPM apps, usually from a RHEL 
update server, which means that there aren't any major changes, and we can 
live happily knowing that the machine wont randomly crash from a poorly 
pkg'ed or poorly installed applicaiton.

>> 2) I was under the impression that it would only work with 2.0.59
>> version of apache - that it had some code in there that would not
>> compile / function with 2.0.52.
> You /must/ use the proper major version number (2.0.x versus 2.2.x), but
> you can probably use the same .so for many point releases without a
> problem. It's always best to have a perfectly-matching shared library,
> though; you might find that there was a bug in a version of Apache that
> caused an odd linking or something, and you could get bitten by that.

I had not realized that.  I'll definitely keep that in mind.  Thx for the 

>> Our tomcat apps are self-contained (non-exploded) wars, and mapping
>> each individual extension becomes a challenge (ie: .jsp, .jspa, jsps,
>> .jpg, .js, .....) , so we found it easier just to map the entire
>> context.
> Agreed. I didn't realize that you were using Tomcat to serve everything
> including static content. You can always do:

I use Tomcat to serve everything (including static content) from everything 
within the war.  This allows us to redeploy updated wars without much 
hassle, not needing to worry about what content is where, and/or if things 
need to get remapped, updated, etc.  I realize that there is prob a slight 
performance hit having to go through 2 servers instead of one, but it also 
allows me to keep my java apps pkged up nice and neat in their own 
locations, and makes automated updates much easier.

> If you're going to front Tomcat with Apache httpd, then serving static
> content from httpd is more efficient because you don't have to
> re-package and forward the request to have Tomcat re-parse everything
> and start the process over again.

That's more or less what I figured, but we've decided to bite the bullet on 
that performance hit for the moment.  Plus, it also allows me to separate my 
tomcat server from my httpd server, and their filesystems as well.  Perhaps 
one day we'll move to shared mounted filesystems, but for the moment, we are 
avoiding the extra configuration that that requires.

>> Would going about it in the "opposite" direction be a bad idea?  Ie:
>> JkMount the entire context and JkUnmount the specific files /
>> extensions that you don't want mounted?
> No, that's perfectly acceptable. I just tend to thing about things in
> terms of "okay, what do I /want/ Tomcat to serve", rather than the other
> way around. But then again, I want httpd to serve my static content and
> Tomcat to serve only my servlets.

Excellent.  Thx again for the help / info!


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message