You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by cowwoc <co...@bbs.darktech.org> on 2011/06/13 19:07:37 UTC
One process per webapp
Hi,
I posted a RFE at https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
asking for the ability to seamlessly deploy webapps into separate JVMs.
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.
Please read the proposal and let me know what you think.
Thanks,
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31836121.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Christopher Schultz-2 wrote:
>
> Can't Netbeans bounce the Tomcat JVM for you?
>
Sure, but if we use the existing mechanism of waiting for for the existing
instance to shut down before restarting it then it takes at least 20 seconds
each time. I'm looking for a second or less.
Christopher Schultz-2 wrote:
>
> If this is just in development, why not just wrap System.loadLibrary()
> in a try/catch block and ignore the exception you get when re-loading
> the native library?
>
> This just seems like it would be a lot of work for not much gain.
>
Because once you get this exception (whether you ignore it or not) you can
no longer invoke any of the native methods (they will throw their own
exceptions). Essentially, the reload operation has failed.
Christopher Schultz-2 wrote:
>
> With no webapps deployed at all? Wow, something is not right. Are you
> sure you have enough memory installed on your dev instance?
>
>> Starting
>> up a new instance is fairly quick. Shutting down takes a while.
>
> That seems strange... do you have a complicated shutdown procedure for
> your webapp? Tomcat shuts down on my end in very short order when no
> webapps need to be undeployed.
>
I don't think you and I are measuring the same thing. Tomcat loads up in
under 2 seconds, but it takes over 8 seconds to shut down. It is quite
possible that the Netbeans plugin is injecting a sleep() somewhere but I'm
not sure. I know they have a 5 second sleep for the Glassfish plugin. I'm
guessing they had a good reason for adding those calls though. Does Tomcat
provide hooks for integrators to know that the webapp is fully unloaded? How
long does a restart (without a webapp) take on your end?
Christopher Schultz-2 wrote:
>
>> When restarting a webapp, we don't have to wait for the old instance to
>> finish shutting down (which is slow) before transferring access to
>> another
>> Tomcat instance.
>
> If they're going to be using the same port, you do.
>
They wouldn't use the same port.
Christopher Schultz-2 wrote:
>
>> The new instance can simply bind to a different port and
>> the proxy running at port 80 can switch which port it is redirecting
>> requests to.
>
> So... you want Tomcat to also notify a 3rd-party that it's being shut
> down so that a proxy can re-configure itself?
>
No. I would ask the proxy (which would be part of Tomcat) to restart an
instance on my behalf. It would do the necessary communication with the
instance to request a shutdown and listen for lifecycle events.
Christopher Schultz-2 wrote:
>
>> The only snag I can think of is that the old instance might
>> keep files locked on disk (but I think this is no longer the case with
>> Tomcat 7.x)
>
> I don't believe Tomcat locks anything specific. Under certain
> situations, the JVM and the OS conspire to lock certain resources
> (usually .jar files) and that can be a problem.
>
> If you're starting a new instance in parallel, wouldn't you want to do
> it from a separate directory anyway?
>
Good point. We could do that.
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31847022.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gili,
On 6/14/2011 3:28 PM, cowwoc wrote:
> Christopher Schultz-2 wrote:
>>
>> Why bother redeploying, then? Instead of doing "ant redeploy", just do
>> "ant bounce" or something similar.
>
> I am running inside Netbeans (remember the focus here is on improving
> development productivity, less so on improving production deployments).
> Modifying what they run under the hood is probably not going to be trivial.
Can't Netbeans bounce the Tomcat JVM for you?
If this is just in development, why not just wrap System.loadLibrary()
in a try/catch block and ignore the exception you get when re-loading
the native library?
This just seems like it would be a lot of work for not much gain.
>> If you deploy no webapps, how long does it take Tomcat to start up?
>
> It takes about 10 seconds to shut down and start up a new instance.
With no webapps deployed at all? Wow, something is not right. Are you
sure you have enough memory installed on your dev instance?
> Starting
> up a new instance is fairly quick. Shutting down takes a while.
That seems strange... do you have a complicated shutdown procedure for
your webapp? Tomcat shuts down on my end in very short order when no
webapps need to be undeployed.
> When restarting a webapp, we don't have to wait for the old instance to
> finish shutting down (which is slow) before transferring access to another
> Tomcat instance.
If they're going to be using the same port, you do.
> The new instance can simply bind to a different port and
> the proxy running at port 80 can switch which port it is redirecting
> requests to.
So... you want Tomcat to also notify a 3rd-party that it's being shut
down so that a proxy can re-configure itself?
> The only snag I can think of is that the old instance might
> keep files locked on disk (but I think this is no longer the case with
> Tomcat 7.x)
I don't believe Tomcat locks anything specific. Under certain
situations, the JVM and the OS conspire to lock certain resources
(usually .jar files) and that can be a problem.
If you're starting a new instance in parallel, wouldn't you want to do
it from a separate directory anyway?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk330RgACgkQ9CaO5/Lv0PCH6ACfTAZ1m0wSocjfvnfLeYHegzbd
BJAAoLAFzIa5fQ/V/k3GYFPtUw6qKjm2
=/62c
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Christopher Schultz-2 wrote:
>
> Why bother redeploying, then? Instead of doing "ant redeploy", just do
> "ant bounce" or something similar.
>
I am running inside Netbeans (remember the focus here is on improving
development productivity, less so on improving production deployments).
Modifying what they run under the hood is probably not going to be trivial.
> * Faster webapp redeploys if the entire JVM is restarted. I'm aiming for
> one
> second but currently we're at ten seconds.
Christopher Schultz-2 wrote:
>
> Tomcat simply takes a certain amount of time to start. The fewer things
> you have configured at startup the better, but Tomcat starts up pretty
> quickly. Generally speaking, it's your webapp that is going to take a
> long time to start up if you have lots of things happening in
> ServletContextListeners, load-on-startup Servlets, etc.
>
> If you deploy no webapps, how long does it take Tomcat to start up?
It takes about 10 seconds to shut down and start up a new instance. Starting
up a new instance is fairly quick. Shutting down takes a while.
When restarting a webapp, we don't have to wait for the old instance to
finish shutting down (which is slow) before transferring access to another
Tomcat instance. The new instance can simply bind to a different port and
the proxy running at port 80 can switch which port it is redirecting
requests to. The only snag I can think of is that the old instance might
keep files locked on disk (but I think this is no longer the case with
Tomcat 7.x)
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31845924.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gili,
On 6/13/2011 9:26 PM, cowwoc wrote:
> Assuming we simply use one webapp per Tomcat instance I'm still looking
> for two changes:
>
> * Restart the entire JVM on webapp redeploy (to avoid JNI and ClassLoader
> problems)
Why bother redeploying, then? Instead of doing "ant redeploy", just do
"ant bounce" or something similar.
> * Faster webapp redeploys if the entire JVM is restarted. I'm aiming for one
> second but currently we're at ten seconds.
Tomcat simply takes a certain amount of time to start. The fewer things
you have configured at startup the better, but Tomcat starts up pretty
quickly. Generally speaking, it's your webapp that is going to take a
long time to start up if you have lots of things happening in
ServletContextListeners, load-on-startup Servlets, etc.
If you deploy no webapps, how long does it take Tomcat to start up?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk33o00ACgkQ9CaO5/Lv0PBDmACgi0uBTXZ8RHtFjggelFNWlk48
iZsAnjEsq3bkhYzPZXIuDqcsw+649L9p
=FZoe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Hi Christopher,
Assuming we simply use one webapp per Tomcat instance I'm still looking
for two changes:
* Restart the entire JVM on webapp redeploy (to avoid JNI and ClassLoader
problems)
* Faster webapp redeploys if the entire JVM is restarted. I'm aiming for one
second but currently we're at ten seconds.
Gili
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gili,
>
> On 6/13/2011 1:07 PM, cowwoc wrote:
>> I posted a RFE at
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
>> 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?
>
>> 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.
>
> Parallel deployment is at once orthogonal to and the opposite of what
> you are requesting.
>
>> 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?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk32htcACgkQ9CaO5/Lv0PAGJwCaA020eDYhHSRmgVxALLLisG7z
> 0zgAn1WDZNd+BRnJVD+C/kKUHh6KtotJ
> =o0Md
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31839136.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Christopher Schultz-2 wrote:
>
> So, now you want Tomcat to launch multiple copies of itself as hot
> standbys for /potential future webapp deployments/? We'll never do this.
>
The exact mechanism is not fixed in stone (I'm sure we could improve on the
initial idea). One approach is that administrators should be able to
configure webapps in "development" mode, and in only such a case you'd
launch a hot standby.
Christopher Schultz-2 wrote:
>
>> * A webapp must invoke System.loadLibrary() to use JNI.
>
> Must it? You can load a native library at a higher-level instead of in
> the webapp itself and avoid all of this.
>
That's not good enough. Webapps that use JNI will modify DLLs between
reloads. Even if you If you load the DLL in some parent ClassLoader you'll
still need to unload it every time the webapp is reloaded, otherwise you'll
miss changes to the DLL.
Christopher Schultz-2 wrote:
>
>> * If a library is loaded by one ClassLoader and another ClassLoader
>> invokes
>> System.loadLibrary() the JVM will throw: java.lang.UnsatisfiedLinkError:
>> Native Library x already loaded in another classloader.
>
> I don't believe this has anything to do with ClassLoaders.
>
Yes it does. Read the evaluation of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4286309
You may only load a library into one ClassLoader at a time. The library is
only unloaded from the JVM when the ClassLoader is garbage-collected.
Christopher Schultz-2 wrote:
>
> I don't think the ClassLoader ever unloads the native library. I haven't
> found any documentation that suggests that it will.
>
This was indeed hard to track down. See the evaluation of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4119554 and
http://codethesis.com/tutorial.php?id=1
Worse-case scenario we could run independent tests to verify this but either
way I think we can both agree the safest and easiest way to ensure proper
reloading of native libraries is to restart the JVM.
Christopher Schultz-2 wrote:
>
> Or you can put your .jar that wraps your native library in Tomcat's lib
> directory and take it out of your webapp. That's not the most portable
> solution, but neither is using a native library in the first place.
>
That's not an option because as I've mentioned before the native library is
potentially the very thing you are redeploying.
Christopher Schultz-2 wrote:
>
> It's not a good excuse, but native libraries are a pain in the ass in
> Java. If you use one, be prepared to have your ass hurt.
>
:) With all due respect, they are only painful to use in web containers.
They are extremely simple to use in desktop applications.
Christopher Schultz-2 wrote:
>
> Aah, you are a REST guy. That explains the constant appeals against
> practicality. ;)
>
> If you wrapped your JNI library with a REST interface, couldn't you
> avoid all this foolishness?
>
That's precisely what I'm doing :) I still need to be able to redeploy the
native library though. Think of the native library + RESTful interface +
Tomcat as an "appliance". I'm making regular updates to the library and I
need to restart it quickly to speed up the debugging process.
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31847177.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gili,
On 6/14/2011 3:54 PM, cowwoc wrote:
>>> 1. Always bounce Tomcat directly instead of re-loading the webapp
>
> This is too slow (10-15 seconds) in its current form. If you use the
> mechanism I'm proposing restart time is instant (you have a blank Tomcat
> instance waiting to pick up a new webapp).
So, now you want Tomcat to launch multiple copies of itself as hot
standbys for /potential future webapp deployments/? We'll never do this.
>> 2. Fix the webapp so it doesn't bomb on startup when the library
>> is already loaded
>
> As far as I know what you are proposing is impossible.
Certainly not.
> Here is what I've seen:
>
> * A webapp must invoke System.loadLibrary() to use JNI.
Must it? You can load a native library at a higher-level instead of in
the webapp itself and avoid all of this.
> * If a library is loaded by one ClassLoader and another ClassLoader invokes
> System.loadLibrary() the JVM will throw: java.lang.UnsatisfiedLinkError:
> Native Library x already loaded in another classloader.
I don't believe this has anything to do with ClassLoaders.
> * Tomcat loads each webapp into its own ClassLoader.
True.
> * When reloading a webapp, there is no guarantee that the old ClassLoader
> will get garbage-collected (thereby ensuring that the old library is
> unloaded) before the new webapp is launched. When I reload such webapps, I
> get UnsatisfiedLinkError virtually 100% of the time.
I don't think the ClassLoader ever unloads the native library. I haven't
found any documentation that suggests that it will.
> * There is nothing a webapp can do to prevent this problem. Either each
> webapp needs to run in its own JVM or Tomcat needs to guarantee that the old
> ClassLoader is GCed before loading the new webapp instance.
Or you can put your .jar that wraps your native library in Tomcat's lib
directory and take it out of your webapp. That's not the most portable
solution, but neither is using a native library in the first place.
>>> 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?
>
> Because then every user would have to roll their own solution.
Yes, everyone who wants this solution would have to roll their own. From
what I can recall, you are the first one who has requested this
capability, so I suspect we wouldn't be saving thousands of staff hours
by implementing whatever-it-is that you are suggesting -- something like
a Tomcat-based hypervisor for multiple Tomcats.
> Right now it
> is impossible to reload webapps that use JNI and it is extremely slow to
> reload the entire JVM. Fixing this in the official release would benefit
> anyone wishing to use JNI (or libraries that use JNI) from within Tomcat.
It's not a good excuse, but native libraries are a pain in the ass in
Java. If you use one, be prepared to have your ass hurt.
> Nowadays with the rise of RESTful interfaces, it makes a lot more sense to
> wrap a RESTful interface around libraries that interface with native code.
Aah, you are a REST guy. That explains the constant appeals against
practicality. ;)
If you wrapped your JNI library with a REST interface, couldn't you
avoid all this foolishness?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk331aUACgkQ9CaO5/Lv0PBdywCfZZISEH2dd7d5MvaP1vdT1EBJ
K3kAoLyerD+DbJl0D7L3ucbuc+kZzFPL
=UhCi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gili,
(Sorry, your message was structured in a way I didn't expect, so I
didn't see the lower portion).
On 6/14/2011 3:54 PM, cowwoc wrote:
> Chris, I'm asking for a lot more sophistication than simply restarting the
> JVM. I'm talking about sticking a proxy (on port 80) that acts a front-man.
> Then each webapp run in its own JVM in some custom port. The proxy redirects
> traffic to the custom ports. Reloading webapps would do the following:
>
> * Grab a blank (loaded without any webapps) Tomcat instance from some pool,
> ask it to load the new webapp instance.
> * The new instance runs in a different port than the existing instance
> * We ask the proxy to forward traffic to the new port instead of the old one
> * We ask the old instance to shut down
> * Note that traffic moves across instances instantly (without waiting for
> the old instance to shut down)
The Tomcat team has thus far been unwilling to implement even an HTTP
proxy component due to lack of interest from the community. Given that
the HTTP proxy would be a major requirement to your above solution, I
don't see this happening anytime soon.
If this is something that you would like to design and implement
yourself, donations of code are always welcome. I don't think anyone
around here is going to take on that responsibility, though.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk331swACgkQ9CaO5/Lv0PA0LQCfVybrSezyjMJxC/eHi1nIq1d6
Me8AoLq2f1pOYqLER/ndLhHMtGRJe+/1
=nr2i
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Pid <pi...@pidster.com>.
On 15/06/2011 14:20, cowwoc wrote:
> If this functionality was built into Tomcat
It wouldn't be built into Tomcat, you're asking for a management
application and/or proxy. The first might run inside Tomcat and the
second sits in front of it - frequently implemented with Apache HTTPD
(mod_proxy, mod_jk).
Why should Tomcat duplicate this functionality, when it already exists?
What you're really asking for should be directed at Netbeans, not anyone
here.
p
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Hi Tim,
Tim Funk-2 wrote:
>
> 1) If relying on native - it might be easiest to place the
> System.loadLibrary() and its classes in the common classloader. Then use a
> Valve to call System.loadLibrary() so it's only called once. Hack, yes ...
> also very simple to do. This might allow webapps to be reloaded without a
> problem [depending on the nature of the change.]
>
This won't work. I am modifying the native library in between reloads.
Tim Funk-2 wrote:
>
> 2) apache httpd can easily handle the proxy scenario. Utilize the hot
> standby feature and have it point to the primary Tomcat. Then when you
> wish
> to restart ... you can bring up a new Tomcat which will be configured as
> the
> hot standby. Then shutdown the primary Tomcat and all traffic goes to the
> hot standby. Once the primary is down, change the proxy rules that now the
> failover is the primary and the standby will be located in the config for
> the next new tomcat instance. All the the proxy rules can be in an
> include.
> (a really simple one - probably less then 10 lines) You'd also need some
> httpd graceful restarts in there too to capture the new changes to the
> include proxy rule file. All of the this can probably be easily
> scriptable.
> (Even though there was a desire to avoid scripting)
>
Great. The problem is that I need Netbeans to do all this legwork so that
when I create a new web project I don't have to manually add all of this
configuration. If this functionality was built into Tomcat, everyone work
benefit automatically regardless of what IDE they use. Also note that it
requires the use of Apache httpd which is even more stuff I'd have to
configure/manage. Like I said from the beginning, this is more about
ease-of-use and productivity than it is about a technical challenge. All of
this is technically "doable" right now but it's not easy to do productively.
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31851393.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Mladen Turk <mt...@apache.org>.
On 06/15/2011 02:27 PM, Tim Funk wrote:
> **
> Observations ...
> Hack, yes ...
> also very simple to do. This might allow webapps to be reloaded without a
> problem [depending on the nature of the change.]
> 2) apache httpd can easily handle the proxy scenario.
There are "hacks" and "use that other web server" approaches,
but at the end I'm seeing more and more people are requesting
those features. Simply, there is a (set of) very good reason(s)
why Apache Httpd runs inside multiple child processes.
Since from ground up it offered a descent app isolation this
was (IMHO) it's major reason for a success.
Now that Android finally broke that JNI paranoia, people
are start looking at something outside that given JVM box.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Static content not displaying
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/6/15 Flaherty, Brennen F <fl...@upmc.edu>:
> we have an application that works as expected on tomcat version 6.0.29 on a windows server . If I try to copy the war to a machine running version 6.0.32 none of the static content will display. If I copy the war file to a different machine with version 6.0.29 installed the static content displays correctly. In both cases the non static content displays as it should
>
> Does anyone have any ideas why?
>
Verify how your DefaultServlet (or WebdavServlet) is mapped.
There was a change in 6.0.30 to address this issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50026
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Static content not displaying
Posted by Pid <pi...@pidster.com>.
On 15/06/2011 13:41, Flaherty, Brennen F wrote:
> we have an application that works as expected on tomcat version 6.0.29 on a windows server . If I try to copy the war to a machine running version 6.0.32 none of the static content will display. If I copy the war file to a different machine with version 6.0.29 installed the static content displays correctly. In both cases the non static content displays as it should
>
> Does anyone have any ideas why?
In future, please start a new thread rather than editing & replying to
an existing one, which is called thread-hijacking.
p
Static content not displaying
Posted by "Flaherty, Brennen F" <fl...@upmc.edu>.
we have an application that works as expected on tomcat version 6.0.29 on a windows server . If I try to copy the war to a machine running version 6.0.32 none of the static content will display. If I copy the war file to a different machine with version 6.0.29 installed the static content displays correctly. In both cases the non static content displays as it should
Does anyone have any ideas why?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Tim Funk <fu...@apache.org>.
**
Observations ...
1) If relying on native - it might be easiest to place the
System.loadLibrary() and its classes in the common classloader. Then use a
Valve to call System.loadLibrary() so it's only called once. Hack, yes ...
also very simple to do. This might allow webapps to be reloaded without a
problem [depending on the nature of the change.]
2) apache httpd can easily handle the proxy scenario. Utilize the hot
standby feature and have it point to the primary Tomcat. Then when you wish
to restart ... you can bring up a new Tomcat which will be configured as the
hot standby. Then shutdown the primary Tomcat and all traffic goes to the
hot standby. Once the primary is down, change the proxy rules that now the
failover is the primary and the standby will be located in the config for
the next new tomcat instance. All the the proxy rules can be in an include.
(a really simple one - probably less then 10 lines) You'd also need some
httpd graceful restarts in there too to capture the new changes to the
include proxy rule file. All of the this can probably be easily scriptable.
(Even though there was a desire to avoid scripting)
-Tim
On 6/14/2011 3:54 PM, cowwoc wrote:
<SNIP>
seen:reload the entire JVM. Fixing this in the official release would benefit
anyone wishing to use JNI (or libraries that use JNI) from within Tomcat.
Nowadays with the rise of RESTful interfaces, it makes a lot more sense to
wrap a RESTful interface around libraries that interface with native code.
<SNIP>
JVM. I'm talking about sticking a proxy (on port 80) that acts a front-man.
Then each webapp run in its own JVM in some custom port. The proxy redirects
traffic to the custom ports. Reloading webapps would do the following:
* Grab a blank (loaded without any webapps) Tomcat instance from some pool,
ask it to load the new webapp instance.
* The new instance runs in a different port than the existing instance
* We ask the proxy to forward traffic to the new port instead of the old one
* We ask the old instance to shut down
* Note that traffic moves across instances instantly (without waiting for
the old instance to shut down)
I wouldn't want to try implementing this in terms of simple script files.
It's a lot more involved.
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
>> 1. Always bounce Tomcat directly instead of re-loading the webapp
This is too slow (10-15 seconds) in its current form. If you use the
mechanism I'm proposing restart time is instant (you have a blank Tomcat
instance waiting to pick up a new webapp).
>> 2. Fix the webapp so it doesn't bomb on startup when the library
>> is already loaded
As far as I know what you are proposing is impossible. Here is what I've
seen:
* A webapp must invoke System.loadLibrary() to use JNI.
* If a library is loaded by one ClassLoader and another ClassLoader invokes
System.loadLibrary() the JVM will throw: java.lang.UnsatisfiedLinkError:
Native Library x already loaded in another classloader.
* Tomcat loads each webapp into its own ClassLoader.
* When reloading a webapp, there is no guarantee that the old ClassLoader
will get garbage-collected (thereby ensuring that the old library is
unloaded) before the new webapp is launched. When I reload such webapps, I
get UnsatisfiedLinkError virtually 100% of the time.
* There is nothing a webapp can do to prevent this problem. Either each
webapp needs to run in its own JVM or Tomcat needs to guarantee that the old
ClassLoader is GCed before loading the new webapp instance.
>> 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?
Because then every user would have to roll their own solution. Right now it
is impossible to reload webapps that use JNI and it is extremely slow to
reload the entire JVM. Fixing this in the official release would benefit
anyone wishing to use JNI (or libraries that use JNI) from within Tomcat.
Nowadays with the rise of RESTful interfaces, it makes a lot more sense to
wrap a RESTful interface around libraries that interface with native code.
Christopher Schultz-2 wrote:
>
> It sounds like the OP could just wrap the Tomcat launcher in a script
> that looks roughly like this:
>
> #/bin/sh
>
> while [ 1 ]
> do
> ${CATALINA_HOME}/bin/startup.sh run >> "$CATALINA_OUT" 2>&1
> done
>
> This would start a Tomcat and wait for it to finish, then restart when
> the original JVM came down. I suspect using JMX or whatever, one can
> request a Tomcat shutdown which will ultimately terminate the JVM
> (unless some foolish person launched a non-daemon thread at some point).
> The script will re-start Tomcat.
>
> This just doesn't seem like a difficult thing to implement oneself, nor
> does it seem like something that is widely applicable.
>
Chris, I'm asking for a lot more sophistication than simply restarting the
JVM. I'm talking about sticking a proxy (on port 80) that acts a front-man.
Then each webapp run in its own JVM in some custom port. The proxy redirects
traffic to the custom ports. Reloading webapps would do the following:
* Grab a blank (loaded without any webapps) Tomcat instance from some pool,
ask it to load the new webapp instance.
* The new instance runs in a different port than the existing instance
* We ask the proxy to forward traffic to the new port instead of the old one
* We ask the old instance to shut down
* Note that traffic moves across instances instantly (without waiting for
the old instance to shut down)
I wouldn't want to try implementing this in terms of simple script files.
It's a lot more involved.
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31846107.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 6/14/2011 9:34 AM, Pid wrote:
> On 13/06/2011 22:53, Christopher Schultz wrote:
>>
>> 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.
Not necessarily... we run Tomcat unprivileged so bouncing the JVM just
requires "normal" user access. If you need port 80, use jsvc or one of
the other similar options.
Now, bouncing the JVM from withing the JVM... that requires some creativity.
It sounds like the OP could just wrap the Tomcat launcher in a script
that looks roughly like this:
#/bin/sh
while [ 1 ]
do
${CATALINA_HOME}/bin/startup.sh run >> "$CATALINA_OUT" 2>&1
done
This would start a Tomcat and wait for it to finish, then restart when
the original JVM came down. I suspect using JMX or whatever, one can
request a Tomcat shutdown which will ultimately terminate the JVM
(unless some foolish person launched a non-daemon thread at some point).
The script will re-start Tomcat.
This just doesn't seem like a difficult thing to implement oneself, nor
does it seem like something that is widely applicable.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk33pYkACgkQ9CaO5/Lv0PC8SACfVOfOhDAvgLzv6bdlKnzVJ96i
k50AnRi3Si75/+E1j0ME/YMQESVcFdbY
=jcbN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by cowwoc <co...@bbs.darktech.org>.
Pid * wrote:
>
> You can, right now, start blank Tomcat instances and deploy apps to them
> - managing the instance using JMX.
>
Granted I can do a lot of this myself, but it's a lot of work for every user
to reinvent this wheel. This kind of feature needs to be improved in the
official release.
Pid * wrote:
>
> 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.
>
You don't need to wait. You have a proxy webapp running on port 80 that
redirects traffic to whatever port each webapp runs on. When an admin
restarts a webapp you simply redirect traffic to the port of the new Tomcat
instance (which may differ from the port of the instance you are shutting
down). That way you don't need to wait for the old instance to shut down
(which is slow) before launching the new one.
Pid * wrote:
>
> Tomcat has some memory leak prevention capability (since 6.0.24) but JNI
> memory issues it can't prevent. What problems are you seeing?
>
The new leak prevention is great, but last time I checked it couldn't solve
100% of offending libraries/webapps. Running webapps in their own JVM would
be a 100% fix without having to resort to any magic/hacks.
Gili
--
View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31846007.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Pid <pi...@pidster.com>.
On 13/06/2011 22:53, Christopher Schultz wrote:
> Gili,
>
> On 6/13/2011 1:07 PM, cowwoc wrote:
>> I posted a RFE at https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
>> 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.
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gili,
On 6/13/2011 1:07 PM, cowwoc wrote:
> I posted a RFE at https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
> 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?
> 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.
Parallel deployment is at once orthogonal to and the opposite of what
you are requesting.
> 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?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk32htcACgkQ9CaO5/Lv0PAGJwCaA020eDYhHSRmgVxALLLisG7z
0zgAn1WDZNd+BRnJVD+C/kKUHh6KtotJ
=o0Md
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: One process per webapp
Posted by Federico Fissore <fi...@celi.it>.
for the record, for this very need, with tomcat 6, we made our own
"cloud" of tomcats
we have tens of embedded tomcats running each a single webapp and each
with its own jvm
as needed, we start the same webapp on another server, then switch the
front end proxy setting to forward the traffic to the newly deployed,
finally shutdown the old version
but it's internal development and I can't share but the idea
feel free to ask whatever question
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org