tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: One process per webapp
Date Tue, 14 Jun 2011 13:34:57 GMT
On 13/06/2011 22:53, Christopher Schultz wrote:
> Gili,
> On 6/13/2011 1:07 PM, cowwoc wrote:
>> I posted a RFE at
>> asking for the ability to seamlessly deploy webapps into separate JVMs.
> So you want Tomcat to have an option to run as a supervisor in one JVM
> and deploy webapps to separate JVMs?

You can, right now, start blank Tomcat instances and deploy apps to them
- managing the instance using JMX.

What you can't do, is seamlessly transfer request processing from one
running JVM to another - using Tomcat instances alone - because you
can't exactly determine when one instance releases a port, enabling
another to bind to it.

This is why I referred to parallel deployment, which does permit
seamless transfer to a new version of the app.

>> Tomcat 7.0's parallel deployment sounds nice but it still doesn't solve the
>> JNI and memory leak problems that haunt a single JVM architecture.

Tomcat has some memory leak prevention capability (since 6.0.24) but JNI
memory issues it can't prevent.  What problems are you seeing?

> Parallel deployment is at once orthogonal to and the opposite of what
> you are requesting.

Yeah, my fault, I misread what he was asking.  See above.

>> Please read the proposal and let me know what you think.
> What "single management interface" are you describing in your
> enhancement comments? The Tomcat manager webapp? It's trivial to run a
> manager in each JVM and use that for deployment.
> If you know that your webapp needs to do things such as register a
> shared library on startup, you can do one of two things:
>   1. Always bounce Tomcat directly instead of re-loading the webapp
>   2. Fix the webapp so it doesn't bomb on startup when the library
>      is already loaded
> Tomcat provides the manager webapp and ant tasks to access it, plus a
> toolbox of scripts to start/stop/etc. Tomcat. Your needs seem to be
> fairly specific... why not just roll your own solution?

Bouncing a JVM requires admin access to the local operating system,
which you probably wouldn't want to give to a Tomcat application.

Assuming I've understood correctly this time.


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

View raw message