I'd like to run a web container where each webapp runs in its own process (JVM). Incoming requests get forwarded by a proxy webapp running on port 80 to individual webapps, each (webapp) running on its own port in its own JVM.
This will solve three problems:
Webapps using JNI (where the JNI code changes between restarts) cannot be restarted. There is no way to guarantee that the old webapp has been garbage-collected before loading the new webapp, so when the code invokes System.loadLibrary() the JVM throws: java.lang.UnsatisfiedLinkError: Native Library x already loaded in another classloader.
Libraries leak memory every time a webapp is reloaded, eventually forcing a full server restart. Tomcat has made headway in addressing this problem but it will never be completely fixed.
Faster restarts. The mechanism I'm proposing would allow near-instant webapp restarts. We no longer have to wait for the old webapp to finish unloading, which is the slowest part.
I've posted a RFE here and here. I'd like to know what you think.
Does any existing web container do this today?
I'm closing this question because I seem to have run into a dead end: http://tomcat.10.n6.nabble.com/One-process-per-webapp-td2084881.html
As a workaround, I'm manually launching a separate Jetty instance per webapp.
Can't you just deploy one app per container and then use DNS entries and reverse proxies to do the exact same thing? I believe Weblogic has something like this in the form of managed domains.
No, AFAIK, none of them do, probably because Java web containers emphasize following the servlet API - which spins off a thread per http request. What you want would be a fork at the JVM level - and that simply isn't a standard Java idiom.
If I understand correctly you are asking for the standard features for enterprise quality servers such IBM's WebSphere Network Deployment (disclaimer I work for IBM) where you can distribute applications across many JVMs, and those JVMs can in fact be distributed across many physical machines.
I'm not sure that your fundamental premise is correct though. It's not necessary to restart a whole JVM in order to deploy a new version of an application. Many app servers will use a class-loader strategy that allows them to discard a version of an app and load a new one.
Related
What is the Java equivalent of the .net Recycle for web apps in IIS.
This is when using Java on a linux machine outside of IIS.
Is it just to stop and start the application?
Not really - IIS and JVM work in different ways. When you say recycling in IIS, it's basically restarting the Worker process. Each Web Application deployed to IIS is under an application pool and worker process.
In case of java, it's not like that. The whole App server runs on a jvm and you have different Web applications deployed into the App server which runs within the app server.
You could use DB connection pools or Apache commons pool for pooling (Some of your expensive objects you reuse) which can be refreshed but not exactly in a way like IIS.
Even though this would be a nice feature - in reality if you ever
reach a situation of needing to refresh application pool, your
code/dll(may be 3rd party) is the culprit. There would definitely be a
memory leak which needs to be addressed! Also when you recycle the session state might be lost. Apparently users logged in would get logged out (and if they are in the middle of a transaction they might loose data).So it could lead to a very volatile situation!
Update
You could use stuff like Terracotta which handles memory management.
Usually JEE servlet containers offer the option of reloading the application. i.e. Tomcat has a Reload button for each app on the manager console.
It also has a button that triggers a full garbage collection, by the way.
I need to run two webapps on a ubuntu VPS but one(my own webapp) prefers to run in Tomcat & other(Solr webservice) is preferable in Jetty. But I think running a separate server for each webapp would be consuming more resources (like memory consumption would be higher) than both the webapps running on same server, isn't it ?
What may be the other bad if I run both Tomcat & Jetty on a single machine for production use?
A couple of things I can think of, some of which you've mentioned:
more resources are consumed (memory usage of two containers running
is generally going to be more than one container running). Also, there could be implications for things like database connections and caching if you have two containers instead of one.
containers have to run on different ports (but there are ways to make it appear to the site visitor that they're on the same port)
don't forget that containers generally listen on more than one port, so you'll have to make sure you avoid conflicts (think of tomcat shutdown port, etc).
Having said that, I run tomcat and jetty side by side all the time on my dev machine and things work just fine. But development, not performance, is my major goal when running on my dev machine.
Running Tomcat and Jetty in the same machine is something that "performance wise" is not so "heavy", I have both running (almost) all the time in my dev machine... in production I am using only Tomcat (running multiple web services in the same container - mainly my web services + Solr) and I do not experience major differences on performance in both scenarios. So I would say that it depends on your needs... personally I tend to prefer to simplify my production setup and avoid having multiple containers in multiple ports on my servers. Furthermore, Tomcat does seem to be more popular solution for java container (http://zeroturnaround.com/rebellabs/the-great-java-application-server-debate-with-tomcat-jboss-glassfish-jetty-and-liberty-profile/), this does not however mean it is the best one for all scenarios. I personally tend to stick with one Tomcat in production...
Yes, it does consume more resources to run two instead of one, but for development purposes it shouldn't be a problem as long as your personal computer isn't terribly under powered. Other than that, you will have to resolve any port conflicts that come up when you start the second process. The error messages should tell you what port is conflicted and all port numbers are configurable.
We have several Java web-applications that need to be deployed on the same machine, over tomcat. The web-applications are not related to each other. Some of them do intensive I/O and CPU operations and consume much memory.
Under the above conditions, which approach is recommended - having a single tomcat with multiple webapps, or multiple tomcats each running a single webapp ?
If all webapps are deployed on the same tomcat, is there a way to guarantee minimum resources per webapp ? I.e. minimum amount of memory, number of threads, etc.
Thanks,
Arnon.
What we did at our company is we run 1 application per instance of Tomcat. We originally started with multiple instances and it occurred occasionally that one application would affect the other, especially if you had to restart the Tomcat instance.
One thing that might be worth evaluating is Spring's TC Server.
http://www.springsource.com/developer/tcserver
Similar to #tjg184 's experience. I would recommend running a tomcat per application instance. If you have a decent config and process management system, the incremental cost is not all that high and it gives you the best isolation possible without separate vm's for each tomcat instance. You could start with a single tomcat and some solid monitoring and then see if you need to move to one tomcat per app.
I am working on a web-based application which is deployed in the Tomcat server. In our local dev enviroemt, when we start the Tomcat server it spawns only one java process which keeps running. However, an issue has been reported in production where the CPU usage for java process has gone up and there are multiple java processes which have been spawned.
There is no other java application running, so this must have been spawned from Tomcat itself. What is the reason that in our development enviroment there is only one java process while in production multiple java processes have been spawned by Tomcat and how to correct it.
Regards,
Dev
Unlike Apache HTTPD, Tomcat doesn't spawn processes on its own (it uses multiple threads to serve multiple clients) so you should look elsewhere. For example, how do you deploy your application to the Tomcat. Could it be something like a buggy deployment script?
Also, what other applications run on this Tomcat container?
What you see are most likely multiple threads that the version of top or ps shows on the production box, while you don't see them on the local one.
In production you most likely face a much higher workload, so that requests are served in parallel, while on the local box Tomcat gets away with less threads.
I have read that it is possible with Tomcat 5.5+ to deploy a war to a Tomcat server without a restart. That sounds fantastic but I guess I am too skeptical about this functionality and it's reliability. My previous experience (with Websphere) was that it was a best practice to restart the server to avoid memory problems, etc. So I wanted to get feedback as to what pitfalls might exist with Tomcat.
(To be clear about my experience, I developed java web apps for 5 years for a large company that partitioned the app developers from the app server engineers - we used Websphere - so I don't have a lot of experience with running/configuring any app servers myself)
In general, there are multiple type of leaks and they apply to redeploy-scenarios. For production systems, it's really the best to perform restarts if possible, as there are so many different components and libraries used in todays applications that it's very hard to find them all and even harder to fix them. Esp. if you haven't got access to all source code.
Memory leaks
Thread and ThreadLocal leaks
ClassLoader leaks
System resource leaks
Connection leaks
ClassLoader leaks are the ones which bite at redeployment.
They can be caused by everything. Really, i mean everything:
Timers: Timers have Threads and Threads created at runtime inherit the current context class loader, which means the WebappClassloader of Tomcat.
ThreadLocals: ThreadLocals are bound to the thread. App servers use Thread pools. When a ThreadLocal is bound to a Thread and the Thread is given back to the pool, the ThreadLocal will stay there if nobody removes() it properly. Happens quite often and very hard to find (ThreadLocals do not have a name, except the rarely used Spring NamedThreadLocal). If the ThreadLocal holds a class loaded by the WebappClassloader, you got a ClassLoader leak.
Caches: e.g. EhCache CacheManager
Reflection: JavaBeans Introspector (e.g. holding Class or Method caches)
JDBC Drivers: they shouldn't be in the .war file anyway. Leak due to static registry
Static libraries which cache ClassLoaders, such as Commons-Logging LogFactory
Specific to Tomcat, my experience is as follows:
For simple apps with "clean" libraries, it works fine in Tomcat
Tomcat tries very hard to clean up classes loaded by the WebappClassloader. For example, all static fields of classes are set to null when a webapp is undeployed. This sometimes leads to NullPointerExceptions when code is run while the undeployment is happening, e.g. background jobs using a Logger
Tomcat has a Listener which cleans up even more stuff. Its called org.apache.catalina.core.JreMemoryLeakPreventionListener and was submitted recently to Tomcat 6.x
I wrote a blog post about my experience with leaks when doing redeployment stresstesting - trying to "fix" all possible leaks of an enterprise-grade Java Web Application.
Hot deployment is very nice as it usually is much faster than bringing the server up and down.
mhaller has written a lot about avoiding leaks. Another issue is for active users to have their session survive the application "reboot". There are several things that must be taken care of, but which all in all means that their session must be serializable and THEN deserialize properly afterwards. This can be a bit tricky if you have stateful database connections etc, but if your code is robust against database hickups anyway that shouldn't be too bad.
Also note that some IDE's allow updating code inside the WAR (in the same way as applications) when saving a modified source file, instead of having to redeploy. MyEclipse does this rather nicely.