Number of Web Applications in one Tomcat

[Ahmed, Tarek]

Hi all,

TLDR? Do you deploy one web application per tomcat instance or several?

-----------------------

The long story:

I'd like to sound out your opinion regarding the number of web
applications deployed in one tomcat instance. The reason is, that at my
place of work the developers prefer one webapp per tomcat, the admins
would rather have as many webapps as possible in one tomcat instance
(yeah, that's devops at its finest ;-)  ). As a developer I'm probably
prejudiced, but the argument goes as follows:


OPS (one tomcat, many webapps):

- Saves memory (each tomcat has a memory footprint even without a web
application running)

- Saves extra file systems for each tomcat (logs, tomcat installation,
temp directory)

- Saves nagios monitoring configuration

- Saves separate ports (security considerations)

- Saves work distributing security patches


DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

- If one webapp goes haywire, it may crash the rest of them (OOM, no
more threads, etc.)

- For bug fixes in one application, you may need to restart the complete
tomcat instance. Auto (re)deploy takes you only so far, since loaded
classes may not always be unloaded cleanly, threads not closed etc. This
is not always something that can be solved in your own code, third party
libraries may cause problems, too (we had some issues with quartz and
infinispan here).

- If you ever need to profile your application in production, there is
much less noise when analysing heap, thread dumps, cpu usage etc.

- I might even think there is some improved security if webapps are
isolated in several processes vs. being deployed in one VM (security
arguments always work well with OPS :-)  )


So, I want to get away from the one-tomcat-multiple-webapps scenario.
One thing I started doing to subvert this policy is using spring boot
with embedded tomcats which is cool in a lot of ways but not always
feasible.

What are your practices? Are there further pros and cons for one way or
the other? Thanks so much for any input,

many greetings,

tarek
--
Signatur
Tarek Ahmed
Softwareentwicklung


DIMDI
Deutsches Institut fÃŒr
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: [phone]
Fax: [phone]
***@dimdi.de <mailto:***@dimdi.de>
www.dimdi.de <https://www.dimdi.de>

tick Das DIMDI unterstÃŒtzt die Vereinbarkeit von Beruf und Familie und
ist entsprechend zertifiziert.



Das DIMDI ist ein Institut im GeschÀftsbereich des Bundesministeriums
fÃŒr Gesundheit (BMG).

[PURVIS, Robert (NHS DIGITAL)]

We have had a single tomcat with multiple applications (10 or more) for many years (since 2002), and are now separating them. The main reason being that when one application crashes it can bring down the whole tomcat (e.g. oom errors).

Robert Purvis
***@nhs.net<mailto:***@nhs.net>



From: Ahmed, Tarek <***@dimdi.de>
Sent: 29 October 2018 08:00
To: ***@tomcat.apache.org
Subject: Number of Web Applications in one Tomcat


Hi all,

TLDR? Do you deploy one web application per tomcat instance or several?

-----------------------

The long story:

I'd like to sound out your opinion regarding the number of web applications deployed in one tomcat instance. The reason is, that at my place of work the developers prefer one webapp per tomcat, the admins would rather have as many webapps as possible in one tomcat instance (yeah, that's devops at its finest ;-) ). As a developer I'm probably prejudiced, but the argument goes as follows:



OPS (one tomcat, many webapps):

- Saves memory (each tomcat has a memory footprint even without a web application running)

- Saves extra file systems for each tomcat (logs, tomcat installation, temp directory)

- Saves nagios monitoring configuration

- Saves separate ports (security considerations)

- Saves work distributing security patches



DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened availablity (e.g., our fattest tomcat contains 32 web services. It takes 4 minutes to start)

- If one webapp goes haywire, it may crash the rest of them (OOM, no more threads, etc.)

- For bug fixes in one application, you may need to restart the complete tomcat instance. Auto (re)deploy takes you only so far, since loaded classes may not always be unloaded cleanly, threads not closed etc. This is not always something that can be solved in your own code, third party libraries may cause problems, too (we had some issues with quartz and infinispan here).

- If you ever need to profile your application in production, there is much less noise when analysing heap, thread dumps, cpu usage etc.

- I might even think there is some improved security if webapps are isolated in several processes vs. being deployed in one VM (security arguments always work well with OPS :-) )



So, I want to get away from the one-tomcat-multiple-webapps scenario. One thing I started doing to subvert this policy is using spring boot with embedded tomcats which is cool in a lot of ways but not always feasible.

What are your practices? Are there further pros and cons for one way or the other? Thanks so much for any input,

many greetings,

tarek
--
Tarek Ahmed
Softwareentwicklung

DIMDI
Deutsches Institut fÃŒr
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: [phone]
Fax: [phone]
***@dimdi.de<mailto:***@dimdi.de>
www.dimdi.de<https://www.dimdi.de>

[tick]

Das DIMDI unterstÃŒtzt die Vereinbarkeit von Beruf und Familie und ist entsprechend zertifiziert.


Das DIMDI ist ein Institut im GeschÀftsbereich des Bundesministeriums fÌr Gesundheit (BMG).


********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in relation to its contents. To do so is strictly prohibited and may be unlawful. Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services.

For more information and to find out how you can switch, https://portal.nhs.net/help/joiningnhsmail

[Leon Rosenberg]

Clearly one webapp per tomcat. Makes everything easier. Also, if your apps
aren't really tiny, the memory overhead of tomcat is minimal compared to
the advantages.

Leon

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or several?
-----------------------
I'd like to sound out your opinion regarding the number of web
applications deployed in one tomcat instance. The reason is, that at my
place of work the developers prefer one webapp per tomcat, the admins would
rather have as many webapps as possible in one tomcat instance (yeah,
that's devops at its finest ;-) ). As a developer I'm probably prejudiced,
- Saves memory (each tomcat has a memory footprint even without a web
application running)
- Saves extra file systems for each tomcat (logs, tomcat installation,
temp directory)
- Saves nagios monitoring configuration
- Saves separate ports (security considerations)
- Saves work distributing security patches
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes 4
minutes to start)
- If one webapp goes haywire, it may crash the rest of them (OOM, no more
threads, etc.)
- For bug fixes in one application, you may need to restart the complete
tomcat instance. Auto (re)deploy takes you only so far, since loaded
classes may not always be unloaded cleanly, threads not closed etc. This is
not always something that can be solved in your own code, third party
libraries may cause problems, too (we had some issues with quartz and
infinispan here).
- If you ever need to profile your application in production, there is
much less noise when analysing heap, thread dumps, cpu usage etc.
- I might even think there is some improved security if webapps are
isolated in several processes vs. being deployed in one VM (security
arguments always work well with OPS :-) )
So, I want to get away from the one-tomcat-multiple-webapps scenario. One
thing I started doing to subvert this policy is using spring boot with
embedded tomcats which is cool in a lot of ways but not always feasible.
What are your practices? Are there further pros and cons for one way or
the other? Thanks so much for any input,
many greetings,
tarek
--
Tarek Ahmed
Softwareentwicklung
DIMDI
Deutsches Institut fÃŒr
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln
Tel.: [phone]
Fax: [phone]
www.dimdi.de
[image: tick] Das DIMDI unterstÃŒtzt die Vereinbarkeit von Beruf und
Familie und ist entsprechend zertifiziert.
Das DIMDI ist ein Institut im GeschÀftsbereich des Bundesministeriums fÌr
Gesundheit (BMG).

[Olaf Kock]

Post by Ahmed, Tarek
TLDR? Do you deploy one web application per tomcat instance or several?

As you list the arguments quite well, I'd add my answer "it depends":
General rule of thumb, to be executed in that order: If they're too few
applications to worry about (and if they're stable): Don't worry, One
server.

If they're completely unrelated and have different stakeholders and/or
maintenance intervals: That's a good argument for multiple servers

If there are unstable applications (in the sense of actively maintained,
forcing frequent redeployments): Another good argument for multiple servers.

If there have been problems in the past with load/memory etc: Good
argument for multiple servers.

This /might/ end up as one app per server, but the number one is not the
end goal. There are typically some related apps, with the same
maintenance intervals and stakeholders - unless one of them is
problematic, I group them together.

I hope that helps.

Olaf


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

[Mark Thomas]

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or several?

No firm opinion one way or the other, just some commentary.

Post by Ahmed, Tarek
-----------------------
I'd like to sound out your opinion regarding the number of web
applications deployed in one tomcat instance. The reason is, that at my
place of work the developers prefer one webapp per tomcat, the admins
would rather have as many webapps as possible in one tomcat instance
(yeah, that's devops at its finest ;-)  ). As a developer I'm probably
- Saves memory (each tomcat has a memory footprint even without a web
application running)

The Tomcat overhead is <20MB. Apps are typically a lot more. This
doesn't look like a strong argument to me.

Post by Ahmed, Tarek
- Saves extra file systems for each tomcat (logs, tomcat installation,
temp directory)

The resources in question are small in number and size. Again, this
doesn't look like a strong argument to me.

Post by Ahmed, Tarek
- Saves nagios monitoring configuration

This is an interesting one. How well can the monitoring distinguish one
app from another. Given shared memory, shared thread-pools etc., per app
details could be tricky to determine.

Post by Ahmed, Tarek
- Saves separate ports (security considerations)

I don't follow the argument here.

Post by Ahmed, Tarek
- Saves work distributing security patches

A split CATALINA_HOME / CATALINA_BASE approach can help a lot with this
issue.
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE

Post by Ahmed, Tarek
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

Post by Ahmed, Tarek
- If one webapp goes haywire, it may crash the rest of them (OOM, no
more threads, etc.)

Fair point.

Post by Ahmed, Tarek
- For bug fixes in one application, you may need to restart the complete
tomcat instance. Auto (re)deploy takes you only so far, since loaded
classes may not always be unloaded cleanly, threads not closed etc. This
is not always something that can be solved in your own code, third party
libraries may cause problems, too (we had some issues with quartz and
infinispan here).

These issues usually are solvable but you need to know about them in
advance to code the necessary workarounds / protections.

Post by Ahmed, Tarek
- If you ever need to profile your application in production, there is
much less noise when analysing heap, thread dumps, cpu usage etc.

Fair point.

Post by Ahmed, Tarek
- I might even think there is some improved security if webapps are
isolated in several processes vs. being deployed in one VM (security
arguments always work well with OPS :-)  )

Possibly. The strength of the security argument depends on the
circumstances. I suspect OPS can construct an equally strong security
based argument for single instances.

Post by Ahmed, Tarek
So, I want to get away from the one-tomcat-multiple-webapps scenario.
One thing I started doing to subvert this policy is using spring boot
with embedded tomcats which is cool in a lot of ways but not always
feasible.
What are your practices? Are there further pros and cons for one way or
the other? Thanks so much for any input,

I've configured Tomcat instances both ways in the past depending on
circumstances. Generally, the more resources an app uses, the more
likely I am to have an app per instance the more business critical the
app is, the more likely I am to use a dedicated instance. Otherwise, I
tend to opt for a single instance for ease of management.

Mark

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

[Ahmed, Tarek]

sorry, didn't send this to the list, but to mark's address,
t.

Post by Mark Thomas

Post by Ahmed, Tarek
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

Thanks, Mark, this is a really valuable hint. I checked if there was
such a possibility several years ago but either I didn't find it or it
was before v. 7.023. I tried it out now and first tests show that a
speed-up of 200% is possible (have to tweak the optimal number of
threads yet). This is not a solution for a lot of my other issues but it
does  make living with fat tomcats easier.

tarek
--
Tarek Ahmed
Softwareentwicklung


DIMDI
Deutsches Institut fÃŒr
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: [phone]
Fax: [phone]
***@dimdi.de <mailto:***@dimdi.de>
www.dimdi.de <https://www.dimdi.de>

tick Das DIMDI unterstÃŒtzt die Vereinbarkeit von Beruf und Familie und
ist entsprechend zertifiziert.



Das DIMDI ist ein Institut im GeschÀftsbereich des Bundesministeriums
fÃŒr Gesundheit (BMG).

[logo]

Mark,

<snip>

Post by Mark Thomas

Post by Ahmed, Tarek
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

<snip>

do you mind to tell me how? Or what option to search for?

Thank you.

Peter

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

[Ahmed, Tarek]

Post by logo
Mark,
<snip>

Post by Mark Thomas

Post by Ahmed, Tarek
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

<snip>
do you mind to tell me how? Or what option to search for?

Since I've already searched (and found it): Look at this page:
https://wiki.apache.org/tomcat/HowTo/FasterStartUp#Starting_several_web_applications_in_parallel

"With Tomcat 7.0.23+ you can configure it to start several web
applications in parallel. This is disabled by default but can be enabled
by setting the startStopThreads attribute of a *Host* to a value greater
than one."

cheers,

tarek

[Torsten Krah]

Post by Ahmed, Tarek
"With Tomcat 7.0.23+ you can configure it to start several web
applications in parallel. This is disabled by default but can be enabled
by setting the startStopThreads attribute of a *Host* to a value greater
than one."

But be aware that you may run into problem with this one - look e.g.
here:

https://www.mail-archive.com/***@tomcat.apache.org/msg127141.html

Cheers

Torsten

[Jäkel, Guido]

-----Original Message-----
Sent: Tuesday, October 30, 2018 2:55 PM
Subject: Re: Number of Web Applications in one Tomcat

Post by Ahmed, Tarek
"With Tomcat 7.0.23+ you can configure it to start several web
applications in parallel. This is disabled by default but can be enabled
by setting the startStopThreads attribute of a *Host* to a value greater
than one."

But be aware that you may run into problem with this one - look e.g.
Cheers
Torsten

I'm pretty sure that this problem is just caused by malformed applications that include some XML stuff inside the application that MUST NOT include, but have to be provided instead by the platform -- e.g. as JVM endorsed libs. A common case is that application A provide and register some implementation of an API at JVM level and application B provide this also, but with another version. Then, one of the application will use at runtime another lib as at compile time.

Without parallel start, this might seem to work (or not) in a stable way. But with parallel start, you get race conditions.
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

[Torsten Krah]

Post by Jäkel, Guido
I'm pretty sure that this problem is just caused by malformed
applications that include some XML stuff inside the application that
MUST NOT include, but have to be provided instead by the platform --
e.g. as JVM endorsed libs. A common case is that application A
provide and register some implementation of an API at JVM level and
application B provide this also, but with another version. Then, one
of the application will use at runtime another lib as at compile
time.
Without parallel start, this might seem to work (or not) in a stable
way. But with parallel start, you get race conditions.

The whole xml stack used is from the JVM (no custom xerces, xalan etc
added to WEB-INF/lib) - so i don't know where to look for something
which should not be in "my" local libs.

And there is no ClasscastException or LinkageError here - its the
parser itself who does fail:

Caused by: org.xml.sax.SAXParseException; lineNumber: 476;
columnNumber:
97; src-resolve: Name 'ehcache:resource-unit' kann nicht als 'type
definition'-Komponente aufgelöst werden.

But i am happy to continue that discussion in the original thread
because i am still interested in getting the root cause because at the
moment parallel startup is disabled because of that error.

Cheers

Torsten

[logo]

Tarek,

Post by Ahmed, Tarek

Post by logo
Mark,
<snip>

Post by Mark Thomas

Post by Ahmed, Tarek
DEV (one webapp per tomcat)
- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

<snip>
do you mind to tell me how? Or what option to search for?

https://wiki.apache.org/tomcat/HowTo/FasterStartUp#Starting_several_web_applications_in_parallel
"With Tomcat 7.0.23+ you can configure it to start several web
applications in parallel. This is disabled by default but can be enabled
by setting the startStopThreads attribute of a *Host* to a value greater
than one."
cheers,
tarek

that's nice, Thanks

Peter

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

[Christopher Schultz]

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

Tarek,

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or
several?

I usually deploy one webapp per JVM/tomcat instance. I do this so that
a problem in one webapp doesn't take-down the others. It's as simple
as that. The other benefits are being able to service that one JVM
without taking down N webapps -- just one, and also being able to run
under different JVMs, system libraries, etc. without having to test
each application for compatibility.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvXDYMACgkQHPApP6U8
pFgNgw/+O790RNVYpFtPKotyUT4ucPJbuVgYRcj/h+xcbw2REZurFzinXv82JSf7
A5m2zDYWLKFNi3x5Wu7rEWZvWc7xTCBz2E2BiwV9jfFX/Los8zuk3xo0xzHOJSFR
bNHnVLLws1Uj44dcsdYS4R6ZqZvJkgWTI9fnDlg0WbKW2zXscxgGO/+5887SrEB7
bgvwibe1tyBLosn+Sfx6O0Pab7w206OT8MHK+eFtXeE68bkfr1re4ykZV/DTTE4n
nEMCbysC7M2CCNElkQZNUe4MEIo9UWXkVnpj7zK3sVa9teawFWrZAx2uxGV/gsQX
PL+PqS6AAcQJh5Tesao/KjE83mjGGF0+CjuN1jl68g7U4rhCVPJSThsA11JxIcv4
jxJtPDbygK+11YBxaQZJY5QaeIvmnFQEaA5Svo/Em6HXOfqZHl9QJERdKQErMM5x
2O/8bwOIvYGShEOn2FwMYTMo1UPv9Yeek1BHXGtGdOhuw0/udVbFdCB6uh416uy3
xHfA2hJEXq/gnqJRWDjTj5lEEKAaXAkTm+FjaOW0VQMKKDNT3DKVs3vIpWfsSNnK
qlk4PFRgDZrp3A8OT+MX39lcMrSdvra9zU5lg1nALVrZDP7I2FTI55QNSqCzpo76
cCybiyWgy4urq5fokprewjHwrQzMiE1lKXS9RfrdVSVwYToyi1E=
=5z9/
-----END PGP SIGNATURE-----

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

[Igal Sapir]

Tarek,

Post by Leon Rosenberg
Clearly one webapp per tomcat. Makes everything easier. Also, if your
apps aren't really tiny, the memory overhead of tomcat is minimal
compared to the advantages.

+1

Post by Leon Rosenberg
I usually deploy one webapp per JVM/tomcat instance. I do this so that
a problem in one webapp doesn't take-down the others. It's as simple
as that. The other benefits are being able to service that one JVM
without taking down N webapps -- just one, and also being able to run
under different JVMs, system libraries, etc. without having to test
each application for compatibility.

+1

Also, if you end up with a much larger heap because you put a bunch of
applications together, then you can run into longer GC cycles (can
happen even with concurrent garbage collectors).  When you have a Full
GC, all of your applications' threads stop, and if it takes long enough,
i.e. more than a fraction of a second, the lack of responsiveness of the
applications will become noticeable.

The whole is greater than the sum of its parts, just that in this case
"greater" is a bad thing.

Igal


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

[Mark H. Wood]

Post by Ahmed, Tarek
TLDR? Do you deploy one web application per tomcat instance or several?

We have one production host with several related webapp.s in a single
Tomcat instance, and another production host with three instances of
that same single product (i.e. clumps of related webapp.s) in a single
Tomcat instance. It works well.

In development I have at times as many as a dozen of those clumps
running in a single Tomcat, alongside various other applications also
in that single Tomcat. It rarely causes trouble, and in development I
can always bounce it if I need to.

A couple of comments:

o "loaded classes may not always be unloaded cleanly, threads not
closed etc." If I have this, it is either (a) an application bug,
which I should fix, or (b) a buggy dependency, which I should
report and complain about until fixed (or replaced).

o An additional problem with multiple applications per container:
ill-designed dependencies which are only configurable using system
properties, when different applications need different
configurations.
--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[Ahmed, Tarek]

Thanks for your input!

To summarize: Most of us seem to prefer not to have too many web
applications running in one tomcat instance. If, however, it is possible
to run a tomcat with many applications in a stable way it reduces
administrative overhead to do so. The prerequisites for this are that
the applications are mature, handle resources well and don't get too
many updates (we _do_ regular dependency updates, though ...).

On the other hand, if there is - for whatever reason - a regular need of
restarts or re-deployments or if the applications deployed need
individual monitoring or special care or whatever, there is a case for
one application per tomcat.

What do I make of this? There might be a compromise here: Identify those
applications that don't cause trouble and put them into one tomcat
instance. Everything else (new applications, buggy ones no one bothers
to fix anymore, applications that get regular feature updates etc.) are
isolated in their own tomcat instances. As soon as those become stable
we can move them to (one of) the fat tomcat(s).

Sounds like something I might get through :-)

Thanks and greetings,
tarek

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or several?

[...]



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

[André Warnier (tomcat)]

Post by Ahmed, Tarek
Thanks for your input!
To summarize: Most of us seem to prefer not to have too many web
applications running in one tomcat instance. If, however, it is possible
to run a tomcat with many applications in a stable way it reduces
administrative overhead to do so. The prerequisites for this are that
the applications are mature, handle resources well and don't get too
many updates (we _do_ regular dependency updates, though ...).
On the other hand, if there is - for whatever reason - a regular need of
restarts or re-deployments or if the applications deployed need
individual monitoring or special care or whatever, there is a case for
one application per tomcat.
What do I make of this? There might be a compromise here: Identify those
applications that don't cause trouble and put them into one tomcat
instance. Everything else (new applications, buggy ones no one bothers
to fix anymore, applications that get regular feature updates etc.) are
isolated in their own tomcat instances. As soon as those become stable
we can move them to (one of) the fat tomcat(s).
Sounds like something I might get through :-)

And somehow, this sounds a lot like Java GC. It should be possible to automate this..

Post by Ahmed, Tarek
Thanks and greetings,
tarek

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or several?

[...]
---------------------------------------------------------------------

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

[Christopher Schultz]

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

Tarek,

Post by Ahmed, Tarek
Thanks for your input!
To summarize: Most of us seem to prefer not to have too many web
applications running in one tomcat instance. If, however, it is
possible to run a tomcat with many applications in a stable way it
reduces administrative overhead to do so. The prerequisites for
this are that the applications are mature, handle resources well
and don't get too many updates (we _do_ regular dependency updates,
though ...).
On the other hand, if there is - for whatever reason - a regular
need of restarts or re-deployments or if the applications deployed
need individual monitoring or special care or whatever, there is a
case for one application per tomcat.
What do I make of this? There might be a compromise here: Identify
those applications that don't cause trouble and put them into one
tomcat instance. Everything else (new applications, buggy ones no
one bothers to fix anymore, applications that get regular feature
updates etc.) are isolated in their own tomcat instances. As soon
as those become stable we can move them to (one of) the fat
tomcat(s).
Sounds like something I might get through :-)
Thanks and greetings, tarek

Post by Ahmed, Tarek
Hi all,
TLDR? Do you deploy one web application per tomcat instance or several?

Has anyone ever attacked one of your web applications? There are some
fun ways to make an application use a huge amount of memory. Just
because the applications themselves are behaving doesn't mean that all
the users are behaving.

For example, do you have a max POST size set for your application? If
not, I can send your login form a username that is so long it might
exhaust your heap. 2147483647 characters is a LOT of characters.

If you have a max POST size, maybe you don't filter-out PUT requests,
and have Tomcat parsing those for you. Same problem, there.

Just some thing to think about. Most web applications haven't really
been exercised by someone who knows what might break it. Can you
afford for those applications to take each other down because the JVM
becomes unstable? Maybe and maybe not.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvYlTwACgkQHPApP6U8
pFi2uQ/+JTpVnGKJkQTRDyq4XQIXERDmTRJ0ZlIc8z3pFgjGq3QePvjq+EF5c8Vi
O7SCHnti/z/PMNTjLVsDH+Z828BV7nvIteD3+AzG5YQoWTavTeaq/LHPKdvUX/DP
1UDWPYNeFzpp7+bbt0aLlRgO488WaZeYjqwNHlyyLilnqgJbLIw477BmKFXDS+ur
16hUWzti1Hjt6anuQhNavZQPU88UuRNU0GiY4+7ns+kq8to+qxqJS8soP9RNPJ5a
FvS/YwpyMSDcNelzWrADAsEaqA8A0p0iBUFhB05kPPh3xjKAA2qt8p1P6EBgcWgo
JUP4KUh2wGpD6izluVS6TDBtJunMoI9mMGhwgfyLHs6G0sH6e4c3YSxsMxWbCn9A
vWwFyKF4qfDDKsaX9DJ5m4ldsxvWtB3/5PZ4AmYf9HqsiCz9k6zzANBnbL2sMos6
jKuqyF34ahFV5MX0SnN6DUtCUSOkqWK0BcBAK5kUevt9/ouwUnssti4cKBNQiRFy
Ss1YGfbf8m6JJ14K2BqteCLe1tekDJ8z9uPzqug9QNqJ5T4pLAYM6eXkpTXfDjtQ
pyqPKRR+YAHRqcbCeva/D85DVXFDIvXoIJVvW7lvZXAve6zwHzYFr5JO4lizFXXW
RZepakYb7Kph9GIPsDPhISr2PqwLY+wCVVpRRuLDvCW1K6Xk2i8=
=/x7Y
-----END PGP SIGNATURE-----

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

[Ahmed, Tarek]

This post might be inappropriate. Click to display it.

[Christopher Schultz]

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

Tarek,

Post by Ahmed, Tarek
Christopher,

Post by Christopher Schultz
Has anyone ever attacked one of your web applications? There are
some fun ways to make an application use a huge amount of memory.
Just because the applications themselves are behaving doesn't
mean that all the users are behaving.
For example, do you have a max POST size set for your
application? If not, I can send your login form a username that
is so long it might exhaust your heap. 2147483647 characters is a
LOT of characters.
If you have a max POST size, maybe you don't filter-out PUT
requests, and have Tomcat parsing those for you. Same problem,
there.
Just some thing to think about. Most web applications haven't
really been exercised by someone who knows what might break it.
Can you afford for those applications to take each other down
because the JVM becomes unstable? Maybe and maybe not.

I have to assume that our applications are attacked, though so far
at least we have no knowledge of serious incidences. The security
measures taken in the individual applications vary with the
security awareness of the programming team responsible (and, of
course, the criticality of the application).
We are working on increasing this awareness but this is a slow and
ongoing process, and, of course, anyone really competent at hacking
web applications usually finds jobs that are better paid than
software development, so we, as mostly everyone else, will always
lag behind.
Anyway, thanks for the additional argument and for the hint
regarding maxPostSize. This
http://tomcat.apache.org/tomcat-8.5-doc/config/http.html, though,
says, its set to 2097152 characters, which is still a lot of bytes
and more than most applications need. I'll check, how we handle
that :-)

Exactly. 2MiB times the number of allowable connections, which is
something like 10k by default. How big is your heap?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvZyTIACgkQHPApP6U8
pFjphQ//fHhs5fmhebqlOp0mebjq78nXTvjf8ZnLeldulwjJdFzBfk8ySikfZxhD
H/vdq+jwuTRfONNfki60ZN9GGBKUXfzHN4Tagv6xdazWDcVhIi05S56/17BYmToC
WdhD0ujPJTvdqIhMsSMFYItkW6jZZsIfi40SZ2+61mUdXcZANkONT1aWBoUgbbKu
PphKdkrUjpJVrUZVtgSGCoaQZjxBTjPqjlAKgfObExJuYcdwwMUZDU2n5ewLGnS4
sNLQi4/P5bnrDdyJkiXwHNMVAadv9vb4nvAygVYxXcxWPCNnJIo2h6qstO/NejJP
VhtApXfwNW0xPKwVo2wMr5YIRwdzfPTi+mEco6JRSEmAWp2b1vi+XMb2K3worbT1
3KNdzOo52P7oJUVptUA7x4BFfdtXQiOx/zbzOjZTuoQmATIAobIFI2KZDe2fp7dk
UYUGR3G86qhL0XkRghr/52TbQ3+0/X8thmwaVa20xVEl//NtVY/ShLfbTjjgXf+T
2Vm66Bq7AtOUnxB8J6zXZ1U3LddEMJAGqjJJcV+9lNC1SeScVJrUzeuUUm9SfYYF
dSBLnoQopirjIx7YfZf7+ZcLiX0zmYl+hlDK5CIJ226ry6p4XaGO8nALhHvBRvV0
E4ZpSBDiRf9FqxP+lAryl6bYf4aEIsyop4+p+94JOy+0+8qsgmo=
=iI4e
-----END PGP SIGNATURE-----

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

[Jäkel, Guido]

Post by Christopher Schultz
Has anyone ever attacked one of your web applications? There are some
fun ways to make an application use a huge amount of memory. Just
because the applications themselves are behaving doesn't mean that all
the users are behaving.
For example, do you have a max POST size set for your application? If
not, I can send your login form a username that is so long it might
exhaust your heap. 2147483647 characters is a LOT of characters.
If you have a max POST size, maybe you don't filter-out PUT requests,
and have Tomcat parsing those for you. Same problem, there.

Dear Chris,

But that's no argument for or against running more than one application per Tomcat: If you're not aware of such things, one may attack your other Tomcats in the same way because of identical configuration. Of course, if you plan to run a couple of applications per Tomcat, you may also plan to spread it to more than instance to have a fail-over or load balancing . But even if you use a HA-cluster with one App per cluster member: If one is able to crash the Application by a Request on one cluster member, this might be repeated on the other members without noteworthy costs.
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

[Christopher Schultz]

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

Guido,

Post by Jäkel, Guido

Post by Christopher Schultz
Has anyone ever attacked one of your web applications? There are
some fun ways to make an application use a huge amount of memory.
Just because the applications themselves are behaving doesn't
mean that all the users are behaving.
For example, do you have a max POST size set for your
application? If not, I can send your login form a username that
is so long it might exhaust your heap. 2147483647 characters is a
LOT of characters.
If you have a max POST size, maybe you don't filter-out PUT
requests, and have Tomcat parsing those for you. Same problem,
there.

Dear Chris,
But that's no argument for or against running more than one
application per Tomcat: If you're not aware of such things, one
may attack your other Tomcats in the same way because of identical
configuration.

Yes and no.

Presumably, more than one application means more resources required in
general. Since each application might experience "peak" usage
simultaneously, you must over-provision *for both*. That actually
*helps* you against the kind of attack I proposed (more memory is
slightly more difficult to fill than less).

On the other hand, each application has different requirements.
Perhaps one application needs to be able to accept file uploads while
the other one does not. That means that the application which need not
accept large POST requests is now vulnerable because of a shared
resource 9memory) which the other application can allow attackers to
consume.

Post by Jäkel, Guido
Of course, if you plan to run a couple of applications per Tomcat,
you may also plan to spread it to more than instance to have a
fail-over or load balancing . But even if you use a HA-cluster
with one App per cluster member: If one is able to crash the
Application by a Request on one cluster member, this might be
repeated on the other members without noteworthy costs.

Cascade failures can indeed be a serious problem.

It's generally more difficult to crash a Tomcat instance with a single
request. It usually requires multiple requests (sometimes
concurrently) and so that provides the admin more opportunities at
mitigation.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvZykEACgkQHPApP6U8
pFiq+A/8DVWiQY6dZhlclS6IkN/Mah2iyslgpTrqASAO4ZkUf8bj9mZKR/FK0wEn
zBJyYz0K4YxZY5HKFn9oVE2WGQOIJAf3FXh/GY1OFb7PtFanU65QS9q7MCj+TmLX
D1lMfI4MjXqV6NTZsdPXwstCpKxFZ1MMpC6fjCO1cS3vE9pKYn8+OpUWgsL/e5Jj
uqj925911/ZNOUxtibG7E5l9uafadxHhVRa3XYOHzSq6t2+lvQ1NXmMYtDUIyatQ
IeMm++HML1RJBIYe38cMyq5IFg+uPkD5wnPHIFcS3kIkGv8nWBAL8xs+QPsEQoRa
I+tWoMJ5T5Yd+x8aP7ifHGtRs3PHczl07ZS5MJPwL/TUUaYolEYuvo+nMW0sJ6mX
75G6KBexS2oMww+m6jcBIZy9HEsi9LfZhWrUP71D3z86y6pbJLHqW9WfnfK+UH8B
MhOv+++xH6I8sLPPMikvy33Ppt8UfGJneyqOn6DXftw9ri4mXZQLs7XyzQWRjEmF
XWaWKWE8XtyVJwgr2S9Dt4HUJiOjMjcG5DhHXossBMwqemh6PYcbe1/LXAsv7t++
7jOOTgTiBHpgN6Ot5K1Q6qCbs9HvWXQBrDf9ycVsqAejV5gPIFqepoj9iPhFbKd+
Px+s18DcwoB6MgXRT5WtGgEsqRNOScdiC+PrJyzsoGN5MHsHxCI=
=GK5X
-----END PGP SIGNATURE-----

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

[George Stanchev]

This is an interesting discussion. Are there any guides to alleviating management work of such deployments? For example, how do you deal with the port mapping? Or logs - do you collect at a common location or let each app log in its corner ? Can you share configuration across instances such as SSL, JNDI configuration, etc? Any blogs to such approach?

-----Original Message-----
From: Christopher Schultz <***@christopherschultz.net>
Sent: Wednesday, October 31, 2018 9:29 AM
To: ***@tomcat.apache.org
Subject: Re: Number of Web Applications in one Tomcat: THANKS!

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

Guido,

Post by Jäkel, Guido

Post by Christopher Schultz
Has anyone ever attacked one of your web applications? There are some
fun ways to make an application use a huge amount of memory.
Just because the applications themselves are behaving doesn't mean
that all the users are behaving.
For example, do you have a max POST size set for your application? If
not, I can send your login form a username that is so long it might
exhaust your heap. 2147483647 characters is a LOT of characters.
If you have a max POST size, maybe you don't filter-out PUT requests,
and have Tomcat parsing those for you. Same problem, there.

Dear Chris,
But that's no argument for or against running more than one
application per Tomcat: If you're not aware of such things, one may
attack your other Tomcats in the same way because of identical
configuration.

Yes and no.

Presumably, more than one application means more resources required in general. Since each application might experience "peak" usage simultaneously, you must over-provision *for both*. That actually
*helps* you against the kind of attack I proposed (more memory is slightly more difficult to fill than less).

On the other hand, each application has different requirements.
Perhaps one application needs to be able to accept file uploads while the other one does not. That means that the application which need not accept large POST requests is now vulnerable because of a shared resource 9memory) which the other application can allow attackers to consume.

Post by Jäkel, Guido
Of course, if you plan to run a couple of applications per Tomcat, you
may also plan to spread it to more than instance to have a fail-over
or load balancing . But even if you use a HA-cluster with one App per
cluster member: If one is able to crash the Application by a Request
on one cluster member, this might be repeated on the other members
without noteworthy costs.

Cascade failures can indeed be a serious problem.

It's generally more difficult to crash a Tomcat instance with a single request. It usually requires multiple requests (sometimes
concurrently) and so that provides the admin more opportunities at mitigation.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvZykEACgkQHPApP6U8
pFiq+A/8DVWiQY6dZhlclS6IkN/Mah2iyslgpTrqASAO4ZkUf8bj9mZKR/FK0wEn
zBJyYz0K4YxZY5HKFn9oVE2WGQOIJAf3FXh/GY1OFb7PtFanU65QS9q7MCj+TmLX
D1lMfI4MjXqV6NTZsdPXwstCpKxFZ1MMpC6fjCO1cS3vE9pKYn8+OpUWgsL/e5Jj
uqj925911/ZNOUxtibG7E5l9uafadxHhVRa3XYOHzSq6t2+lvQ1NXmMYtDUIyatQ
IeMm++HML1RJBIYe38cMyq5IFg+uPkD5wnPHIFcS3kIkGv8nWBAL8xs+QPsEQoRa
I+tWoMJ5T5Yd+x8aP7ifHGtRs3PHczl07ZS5MJPwL/TUUaYolEYuvo+nMW0sJ6mX
75G6KBexS2oMww+m6jcBIZy9HEsi9LfZhWrUP71D3z86y6pbJLHqW9WfnfK+UH8B
MhOv+++xH6I8sLPPMikvy33Ppt8UfGJneyqOn6DXftw9ri4mXZQLs7XyzQWRjEmF
XWaWKWE8XtyVJwgr2S9Dt4HUJiOjMjcG5DhHXossBMwqemh6PYcbe1/LXAsv7t++
7jOOTgTiBHpgN6Ot5K1Q6qCbs9HvWXQBrDf9ycVsqAejV5gPIFqepoj9iPhFbKd+
Px+s18DcwoB6MgXRT5WtGgEsqRNOScdiC+PrJyzsoGN5MHsHxCI=
=GK5X
-----END PGP SIGNATURE-----

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

B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

[Christopher Schultz]

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

George,

Post by George Stanchev
This is an interesting discussion. Are there any guides to
alleviating management work of such deployments?

It's a little out of scope for this community (formally), but there
may be people here who can share their stories.

Post by George Stanchev
For example, how do you deal with the port mapping?

We assign each dev a number and each application a number. Each pair
of dev+app yields an actual port number. This works great in
development so nobody ever steps on anyone's toes. In other
environments (test, prod, etc.) there is only ever one "dev number"
and that's "the deployer".

Post by George Stanchev
Or logs - do you collect at a common location or let each app log
in its corner ?

We use separate logs, but many logging systems allow for log
aggregation. I know e.g. log4j has a SysLogAppender and you can do
*anything* with that.

Post by George Stanchev
Can you share configuration across instances such as SSL, JNDI
configuration, etc?

We use revision-control for that kind of thing with replaceable
parameters for things like relocatable resources (e.g. database URLs)
and sensitive information (e.g. passwords).

We use "ant" for deployment, which merges the configuration(s) under
revision-control with a set of local settings to build a working
configuration.

Post by George Stanchev
Any blogs to such approach?

Not that I have personally written. Configuration-management and
deployment strategies are typically very environment-specific.

- -chris

Post by George Stanchev
-----Original Message----- From: Christopher Schultz
Applications in one Tomcat: THANKS!
Guido,

Post by Jäkel, Guido

Post by Christopher Schultz
Has anyone ever attacked one of your web applications? There
are some fun ways to make an application use a huge amount of
memory. Just because the applications themselves are behaving
doesn't mean that all the users are behaving.
For example, do you have a max POST size set for your
application? If not, I can send your login form a username that
is so long it might exhaust your heap. 2147483647 characters is
a LOT of characters.
If you have a max POST size, maybe you don't filter-out PUT
requests, and have Tomcat parsing those for you. Same problem,
there.

Dear Chris,
But that's no argument for or against running more than one
application per Tomcat: If you're not aware of such things, one
may attack your other Tomcats in the same way because of
identical configuration.

Yes and no.
Presumably, more than one application means more resources required
in general. Since each application might experience "peak" usage
simultaneously, you must over-provision *for both*. That actually
*helps* you against the kind of attack I proposed (more memory is
slightly more difficult to fill than less).
On the other hand, each application has different requirements.
Perhaps one application needs to be able to accept file uploads
while the other one does not. That means that the application which
need not accept large POST requests is now vulnerable because of a
shared resource 9memory) which the other application can allow
attackers to consume.

Post by Jäkel, Guido
Of course, if you plan to run a couple of applications per
Tomcat, you may also plan to spread it to more than instance to
have a fail-over or load balancing . But even if you use a
HA-cluster with one App per cluster member: If one is able to
crash the Application by a Request on one cluster member, this
might be repeated on the other members without noteworthy costs.

Cascade failures can indeed be a serious problem.
It's generally more difficult to crash a Tomcat instance with a
single request. It usually requires multiple requests (sometimes
concurrently) and so that provides the admin more opportunities at mitigation.
-chris
---------------------------------------------------------------------
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbBOUACgkQHPApP6U8
pFjJKg/+KOX+zbD+fIIPDmUToZYCFgCt8fjWUsoUVStfsMzhLCrQ6j0c6iRkIOMl
9SuaorrIhVAPRDJ3M/7tqij5a/Mf2QdVeTEtdCp9VpHeIREmOewtwDPO5ZgW89P0
QECvZ5VyqgXkWqViWE2l8xxCBj4R/3U9oeUkAMBF56HJQSHogr/LYlsiJx8EU116
tmh9QVDZrStD22qG4Lvj997ePJ9qHCePfprerlNjszS9iZr5CmigSB3mC3YZSj1Z
L202zj65BABHTvN5uk3pnJ+xsWzdf/55+nnMCleww0LeV3fV9EUaoE9ch44u0T1E
Is62vgkPS6IASYnQMc6MPMFqHgcePKuAPMnYmmc8/mId4839h7RYZnaXF75e8Lzk
wksw12XCaigCpRT3Fz64xTCz+//2OIU22Lu4Pff9ZGKqn9MWQIXUzqFrqmpyg+Ot
lWONDyyfTZ8wjL94Ib49ni1ujIgaXdYU/XIPFc1IBazRu9DUUgwsioRVp0JkMuI+
CQ8u4w+2f1KTGYI4k/i9AMzwXHrNTQKHTOrUetqgfY/yp/J9X7Af4Njwt5gpafpD
Jmf3WnhKP1A11bQD93r1++WDll1AZLZcppXdFe4+5Q3fezhiSbL0Pp1HyokhcJ5C
ckuM8VCodPMspHONRbTGRn2TqGal4S9RHnYcb5SOlJrsuPz9CSY=
=XZX9
-----END PGP SIGNATURE-----

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

[André Warnier (tomcat)]

Post by Christopher Schultz
We assign each dev a number and each application a number. Each pair
of dev+app yields an actual port number. This works great in
development so nobody ever steps on anyone's toes. In other
environments (test, prod, etc.) there is only ever one "dev number"
and that's "the deployer".

I don't know if this is original or a system that is aready well-known in this industry,
but that sounds like a really clever idea to me. Our own context is bit different, but I'm
sure there is a way for us to re-use this.
Thanks.


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

[Igal Sapir]

Post by André Warnier (tomcat)

Post by Christopher Schultz
We assign each dev a number and each application a number. Each pair
of dev+app yields an actual port number. This works great in
development so nobody ever steps on anyone's toes. In other
environments (test, prod, etc.) there is only ever one "dev number"
and that's "the deployer".

I don't know if this is original or a system that is aready well-known in this industry,
but that sounds like a really clever idea to me. Our own context is bit different, but I'm
sure there is a way for us to re-use this.

+1

This new feature from BZ 61171 might make like easier for deployments of
such setups:
Add port offset attribute (portOffset?) to Server configuration
https://bz.apache.org/bugzilla/show_bug.cgi?id=61171

Igal

[Christopher Schultz]

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

Igal,

On Thu, Nov 1, 2018 at 7:39 AM André Warnier (tomcat)

Post by André Warnier (tomcat)

Post by Christopher Schultz
We assign each dev a number and each application a number. Each
pair of dev+app yields an actual port number. This works great
in development so nobody ever steps on anyone's toes. In other
environments (test, prod, etc.) there is only ever one "dev
number" and that's "the deployer".

I don't know if this is original or a system that is aready
well-known in this industry, but that sounds like a really clever
idea to me. Our own context is bit different, but I'm sure there
is a way for us to re-use this.

+1
This new feature from BZ 61171 might make life easier for
deployments of such setups: Add port offset attribute (portOffset?)
to Server configuration
https://bz.apache.org/bugzilla/show_bug.cgi?id=61171

Yup. We don't happen to use that feature, but that's just because we
baked everything into our deployment scripts back in 2003. :)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbNDsACgkQHPApP6U8
pFiPhxAAqayojWGqEYrW6K10n7HNXb3OBK7Wzjm02JoB9kiiHn1io7APMpkoKTVg
hL/LhDPpqClJ0Mdq1VRmfG2qICQe2hQXSrIjiB1v+sbuL9c/5xFc9e+6gzG8jWSL
mZmP+aUqV6aAcG0b7cPulTF8YREH0clkSfFQp6eAxVCm7YETPGt0gC5MuYlY4jB2
yK3PiXmoPnRjz87nrFccw3tYpJYbGc3QnOiDfJp6Z6hsYvuE+i0zygU3mjyiFvfL
W7rLq0tkfWwNmiLgFhk4IRiGiiUbjKKeCupcSiMdTDp5vP7507ZACAGED+4kdail
JQ3Tafc608vXuLk78aw6+1e5tHURcB/3HojD1Rwa7iy3E3sNke1ToVWjNZ/z82aN
pJNX8vBYroTHgQU7ZFpF3+UiS6Hh4+nMgn78Gl0yBELBxQVOcqIF91ZjST85zFSZ
Zw2AV8d7ekqzo3tX+5+9vEbTreGdepBwrsF/t35RlwUTXYCZpLuFAdifhseIOnXJ
lCCryd7FsaplhJaKZWEAYqUDle/u7BUclxykKiQXXaJl7TT7xtWDlk0aZ++/S5q9
nncMkc0CeL7xruPSxbamDyrNQCvrB2mNAj/zj4Xa+xjFoY09vdqVt3MVm8HrTYeq
+i2NrdXPf3ucs62cTLMa4tdI5ev26nrLk5SUEEcq+N6Jl2X5wPQ=
=5tQt
-----END PGP SIGNATURE-----

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

[Igal Sapir]

Chris,

On Thu, Nov 1, 2018 at 10:13 AM Christopher Schultz <

On Thu, Nov 1, 2018 at 7:39 AM André Warnier (tomcat)

Post by Christopher Schultz
We assign each dev a number and each application a number. Each
pair of dev+app yields an actual port number. This works great
in development so nobody ever steps on anyone's toes. In other
environments (test, prod, etc.) there is only ever one "dev
number" and that's "the deployer".

<snip/>

This new feature from BZ 61171 might make life easier for
deployments of such setups: Add port offset attribute (portOffset?)
to Server configuration
https://bz.apache.org/bugzilla/show_bug.cgi?id=61171

Yup. We don't happen to use that feature, but that's just because we
baked everything into our deployment scripts back in 2003. :)

Right, given the fact that it was only added to dev a few hours ago
(r1845482) I don't expect anyone to be using it yet ;)

I like your idea of `port = dev + app`. In development, I often find
myself disabling the AJP and SHUTDOWN ports to avoid binding conflicts. In
production, one of the organizations for which I provide support has about
200 different applications, with deployment scripts that sets the different
ports and map the web server accordingly.

Come 9.0.13 the new portOffset feature can make such deployment a little
easier.

Best,

Igal