[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: Changing Sever.xml without restarting Tomcat 8.5
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2018-07-24 16:28:01
Message-ID: ddc0ae5b-14fa-2887-b4dc-96500984a257 () christopherschultz ! net
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Laurie,

On 7/24/18 5:54 AM, Laurie Miller-Cook wrote:
> Hi Chris
> 
> You mentioned the below in your reply
> 
> "You might also want to consider having separate Tomcat instances
> per domain. That might be more manageable, though it will require
> more memory on your server(s)."
> 
> Is there a best practice guide to what we are trying to achieve,
> multiple domains on one server, we are new to Tomcat, so we are
> implementing what we can find in documentation on the web?

The only best-practice advice I can give is "do what is best for your
use-case". Completely un-helpful, I know. I can only tell you what my
own experience has been.

We've gotten a lot of mileage out of multi-instance Tomcat
deployments. We deploy a single application to a single Tomcat
instance, and we have 4 applications to deply. That means that every
node in our deployments are running 4 JVMs each with Tomcat + a single
application.

We find that this gives us the most flexibility at the expense of a
little memory.

> We need to be able to supply each customer the same IP Port, say 80
>  or 443, if we have multiple instances of Tomcat on one server
> then would we need a proxy in front (for wants of better words)
> which could then direct the customers to the correct websites and
> hence get the same IP Port. We also use SSL so I assume wildcard
> certificate would need to be applied to each Tomcat instance?

You would need to have a reverse-proxy, yes. You should have this,
anyway, because trusting a single JVM/Tomcat/application not to go
down for any number of reasons is asking for trouble. So a
proxy+multiple node deployment should already be in your plans.

The TLS certificate issue should be handled at the proxy, using
whatever strategy makes sense for you. I don't know what kinds of
certificates you need, but any decent proxy should allow you to deploy
(virtually) unlimited certificates for any number of domains. Wildcard
certs aren't always the right approach, but this is outside the scope
of our discussion, here. You can configure any certificates you may
need at the proxy. You could do it with Tomcat, too, but ... see my
previous assertion about *needing* a reverse-proxy.

> Would each instance of Tomcat require its own JVM, hence your 
> comment about more memory on the servers, do you know of any 
> resourcing guide lines for multiple instances on Tomcat on one 
> server?
Yes, each instance is a separate JVM. The overhead of a single JVM
isn't much (where "much" is, of course, relative). If your application
can run comfortably in a few MB of heap space then Tomcat's
contribution to your memory footprint is going to be fairly large. But
most Java web applications these days have multi-gigabyte heaps. JVM
and Tomcat overhead is something like 32MiB. That's nothing compared
to the huge amounts of memory your application is likely to require.

Hope that helps,
- -chris

> -----Original Message----- From: Christopher Schultz
> <chris@christopherschultz.net> Sent: Monday, July 23, 2018 7:33 PM 
> To: users@tomcat.apache.org Subject: Re: Changing Sever.xml without
> restarting Tomcat 8.5
> 
> Laurie,
> 
> On 7/23/18 12:25 PM, Laurie Miller-Cook wrote:
>> Hi there,
> 
>> I have an issue where we have multiple virtual hosts in separate
>> base directory's on a single Tomcat installation.  If I need to
>> change something within server.xml I need to restart Tomcat which
>> means I need to do this within an outage window as it affects all
>> of the Websites, is there a way of reloading the server.xml
>> without restarting Tomcat?
> 
>> As a bit of background we have a wildcard domain, so 
>> <clientname>.<Domain>.com so we have created multiple webapp 
>> directories with their own Manage and have multiple entries in
>> the server.xml file for the different hosts.
> 
>> What need to be able to do is, for example, is add another host
>> to the xml site and get that to take effect automatically without
>> the need to restarting Tomcat as this restarts all the other
>> websites and hence gives outages to our customers.
> 
>> Any help would be greatly appreciated.
> 
> Tomcat won't reload server.xml. It's just too complicated to
> determine what has changed and how to perform an in-place reinit
> that only does what is "necessary".
> 
> On the other hand, JMX is very powerful and you can make runtime
> changes to Tomcat using that. Maybe you can consider performing two
> operations whenever you need to add a virtual host:
> 
> 1. Modify the conf/server.xml 2. Issue a JMX command to provision
> the new virtual host in the running Tomcat
> 
> You might also want to consider having separate Tomcat instances
> per domain. That might be more manageable, though it will require
> more memory on your server(s).
> 
> -chris
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltXU5AACgkQHPApP6U8
pFi4RhAAnZ4DtttCS+ak9l+8Y3FN3ULVfc2aXto389mKsd19nqv1xeMz5TwINfDk
++TTYYIR4c2c2vLrcUYGbIjmGtO+thIl4Obb7YFhISYGDHEjpQyrKGXrIN5i9n6R
9WCOSY6lPi3iKQAmfBKEGGv+fRQ57y69uji1ldK/ezkXiBdq3cwXDnRsHkmAmz2+
vYsXh3soSCh1V4Gr2i//ewVD3haBW6AfWqFIV+oAYXjjPcQlgnvjcqy6uxFhLN65
ugbP5DF00o8/B9b5fT18XKdlBKLdrQQzQfdEArh0TQG7V+6LMiTJAgW0T7S6LXX5
eQ1kXytrkTiB83lQxy3UMf95F8Q7uAbiBftZkRxPI64MiXYkBF4a0dPDek+5vEMR
AaBJuotNMxJvgwdEQnTE9Pvv8CtUdTyHI02pCL0pRYsuh3sNbeL5HlOs+fvBdL9m
mSWEE9D1rQw/wCpa1yXKjhlA7/Tfd3FJ7xuGGQql1Qow36xGWLGZdQoto/itvUWx
8uamd4j+3UFJxUr3HWQSCqzM7rPsSuHXUb5EbOtuxIJejQ2BVEFTk1FXC/BCZmHO
Osus5VGoVD2krHSdyWK+R5k1dHv/ilt/AFIw7hqjlLedjzXtTxlEFSbm9GJmKkhZ
ouycIdmPxEh6IjA9CZaIxe7+Xn/uEnqdgwIbUlufT0/EWH30ISA=
=GJN3
-----END PGP SIGNATURE-----

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

[prev in list] [next in list] [prev in thread] [next in thread]