> -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Monday, March 10, 2014 12:15 PM > To: Tomcat Users List > Subject: Re: The Service Component > > Christopher Schultz wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Jeffrey, > > > > On 3/10/14, 10:26 AM, Jeffrey Janner wrote: > >>> -----Original Message----- From: Leo Donahue > >>> [mailto:donahu...@gmail.com] Sent: Friday, March 07, 2014 9:44 AM > >>> To: users@tomcat.apache.org Subject: The Service Component > >>> > >>> Who uses more than one Service in their server.xml and why? I get > >>> that you can have multiple Connectors if you have multiple Service > >>> components but why use multiple connectors? > >>> > >>> Are there any docs on the use cases for these features? > >>> > >> Hi Leo, I may be the only person on this list who does this > >> consistently. I use it as an alternative method of virtual hosting, > >> i.e. each host gets its own <Service> and related sub-structure. > >> The real reason? The default host has to be set to something, and I > >> don't want to maintain some generic host to catch those that come > in. > >> Since I'm running an SaaS environment, really more ASP, a business > >> requirement is that each host appear to the outside world as a > unique > >> physical host, so two customers don't get the same IP address. I > >> could add <Alias> tags for the IP address and all know variations of > >> the hostname, but there's nothing to keep some yahoo admin at a > >> customer site from configuring a DNS entry on an internal DNS server > >> with some name I'm not expecting. Therefore, each <Engine> in each > >> <Service> gets a defaultHost entry pointing to its one and only > >> <Host> entry. > > > > I'm interested in this use case. > > > > Since you have to maintain a <Connector> for every IP address > already, > > how is that different from having a single <Connector> with a bunch > of > > <Alias> elements? How are those different? Or is it that you need > > application isolation in the first place, so this is the best way to > > do it in a single JVM? > > > >> As an added benefit, if I find I need to move a customer from a > >> shared Tomcat setup to a unique Tomcat, all I need to do is set up a > >> new blank Tomcat and move the <Service> structure from one Tomcat to > >> another. Naturally, there's more work needed if I find I need to > give > >> them their own physical server, but that's to be expected. In > >> general, not counting any hardware setup, I can move a host to > >> another tomcat instance with < 2 minutes downtime. > > > > Nice. > > > > It is particularly nice to know that it works, and that the <Service> > element really > (apparently) corresponds to "something real" at the Tomcat level. So > it is apparently not just an "element of order" allowing to group > Connectors with Engine. > Which is contrary to what I imagined, and which I believe definitely > answers the original OP's question (at least the first part). > > And I believe it is worth repeating what was already mentioned earlier > regarding the Service/Connector relationship : > Even if you have only one <Service>, you can have multiple > <Connector>'s inside it, and there are plenty of use cases for that. > And if you have multiple <Service>'s, you can also have more than 1 > <Connector> per <Service>, but each <Connector> (even across > <Service>'s) will still need its own unique listening IP address:Port > combination. > > As to running multiple <Service>'s within the same Tomcat instance, as > opposed to running multiple single-<Service> Tomcat instances : in the > multiple-<Service> scenario, they all share the same JVM, the same > Heap, the same Stack etc. So if you bring one "Service" > down, they all go down. > Which is not the case for multiple Tomcat instances.
True, if you crash the JVM, everything goes away, but that's true for any virtual hosting setup with multiple hosts/Tomcat. However, I have had an app hang and which caused its connector's queue to fill and thus "appearing" to crash, yet the other services were happily chugging away in the JVM. (Yep, they got moved to their own Tomcat instance until the problem was corrected.)
