tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: The Service Component
Date Mon, 10 Mar 2014 17:15:14 GMT
Christopher Schultz wrote:
> Hash: SHA256
> Jeffrey,
> On 3/10/14, 10:26 AM, Jeffrey Janner wrote:
>>> -----Original Message----- From: Leo Donahue
>>> [] Sent: Friday, March 07, 2014 9:44
>>> AM To: 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>
<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.

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

View raw message