tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: tomcat 6 virtual hosting vs apache virtual hosting
Date Wed, 05 Sep 2012 19:09:59 GMT
Hash: SHA1


On 9/5/12 2:43 PM, Charles Richard wrote:
> I'm not completely sure yet about the application segmentation.
> 2nd day on the job and there's lots to do!  I'm not used to this
> method of configuring Tomcat so I'm still trying to make sure I
> understand exactly what is going on and I have very limited time to
> do so.  Apache is used in front of Tomcat which I'm used to doing
> and is using mod_jk.

Okay. Is there every a reason to contact Tomcat directly? That is, are
there any non-AJP Tomcat Connectors that are not unused?

> Whenever I've used this in the past, all apps were off the webapps
> folder and no tomcat virtual host was used.  Apache would do the
> virtual host config and Jkmount the entire tomcat webapps.  I could
> see this not being efficient and the need to use the Tomcat virtual
> hosting, I just need to understand Tomcat virtual hosting a bit
> better.

Tomcat's Virtual Hosting sets up a different <Host> for different
criteria (usually hostname) and requests are routed based upon the
"Host" header in the request. If nothing matches, the Service's
defaultHost (usually called "localhost") is used.

Note that multiple <Host>s in a single <Service> will all share
<Connector>s, so it doesn't matter if you have several connectors
defined where the request comes from: it will go to the right virtual
host. That's important because if you are trying to use different port
numbers (for example) to separate the virtual hosts from one another,
you are just complicating things because they all go to the same
place. Given that there appear to be more layers involved than
strictly necessary, that's another degree of freedom the originally
deplopyers may have considered advantageous in some way.

Each <Host> has its own separate appBase (the default "localhost"
appBase is the "webapps" directory you are used to) so you can deploy
different webapps to each virtual host.

If webapps are deployed in all virtual hosts and don't have any
different configuration from one another, you are just wasting a bunch
of memory because the webapps are completely separately deployed, etc.
You may also waste resources elsewhere because if you have 2 copies of
a webapp that declares a JDBC DataSource with 100 connections to a
backend database, then the backend database now may be expected to
maintain 200 connections.

It's probably worth some time investigating why virtual hosting is
being used at the Tomcat level. On the one hand, you will learn a lot
about the applications you are supporting ;) and on the other, you
will find out if you are using more resources than absolutely necessary.

> Thanks, Charles
> On Wed, Sep 5, 2012 at 3:22 PM, Christopher Schultz < 
>> wrote:
> Charles,
> On 9/4/12 2:13 PM, Charles Richard wrote:
>>>> I've started a new job where the last sysadmin has the
>>>> virtual hosting configured in Tomcat (and Apache).  I'm used
>>>> to only doing virtual hosting with Apache.
>>>> What are the pros and cons of each method?  I'm trying to 
>>>> understand why that would be needed.
> I'd like to add some questions to those posed by André:
> 1. How are you connecting Apache httpd to Tomcat?
> mod_jk/mod_proxy_ajp or mod_proxt_http?
> 2. Do you ever need to access Tomcat directly, or does all traffic
> go through Apache httpd first?
> 3. Does Apache httpd add anything to your environment that you
> can't (or don't want to) do through Tomcat? Perhaps httpd isn't
> even necessary.
> 4. Describe your application segmentation: do you have one or more 
> webapps deployed in each virtual host that are identical *other*
> than the fact that they are deployed on separate virtual hosts?
> For example, does the application in VH A behave differently than
> the same application in VH B? Sometimes, it's the same app with a
> different configuration which changes the kind of advice we might
> give you.
> -chris
>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>> For additional commands, e-mail:
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message