Is there any config in tomcat where in I can mention that start all application at same time when tomcat restarts. This is to avoid latency during tomcat restarts.
The best you can do is configure a suitably large startStopThreads setting for the <Host .../> element in server.xml so each Context starts in a parallel thread.
How successful this is will depend on how many cores you have on your system compared to the number of web applications and the relative start times of each web application.
Full details of the startStopThreads are available in the Tomcat Documentation.
They all start automatically, I'm not sure what else you need.
AFAIK they're started sequentially, one after the other - probably this is what you're aiming at. I'm not aware of a multi-threaded concurrent start, but even if this would be the case, they'd all have an individual startup time anyways, so you might shorten the time, but still have the same problems.
You can counter any problem by making your tomcat available to the outside world only when it has fully been started up (e.g. through proper loadbalancer configuration). If your applications take too long to inintialize, you might want to work on this issue as well.
Related
I'm working on a small servlet-based application with rapid build/deploy/test turn-around. I am finding that the wait time during development for Tomcat 8.0 to auto redeploy (with Host setting 'autoDeploy=true') is quite distracting: it varies between almost immediate and nearly 10 seconds.
I'd like (roughly in order of preference) to:
Configure Tomcat to check for redeployments on every request.
Reduce the time Tomcat waits before polling for redeployments (to, say, 1s).
Or, alternatively, have a convenient way to prompt Tomcat to redeploy immediately as soon as the .war is built. (I'm building/deploying with Ant.)
I've been searching the Tomcat documentation (and SO) for the last 30 minutes and don't see anything for any of these. Am I missing something?
Can anyone recommend an approach (re one of the above) that they found minimized the turn-around time (and distraction)?
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 are trying to access an application from the tomcat which is on a different host, but it is not loading even though the tomcat is running. It was running fine for the past 3 months. We restarted the tomcat now it is working fine.
But, we could not able to zero in on what happened.
Any idea how to trace / what might have caused this?
The CPU usage was normal and the tomcat memory was 1205640.
the memory setting of tomcat are 1024- 2048(min-max)
We are using tomcat 7.
Help much appreciated....thanks in advance.....cheers!!
...also - not sure on Windows - you may be running out of file descriptors. This typically happens when streams are not properly closed in finally blocks.
In addition, check with netstat if you have a lot of sockets remaining open or accumulating in wait state.
Less likely, the application is creating threads and never releasing them.
The application is leaking something (memory, file descriptors, sockets, threads,...) and running over a limit.
There are different ways to track this. A profiler may help or more simply, running JVM dumps at regular intervals and checking what is accumulating. The excellent MAT will help you analyze the dumps.
Memory leak problems are not uncommon. If your Tomcat instance was running for three months and suddenly the contained application became unresponsive maybe that was the case. One solution (and if your resources allow you to do so) could be monitoring that Tomcat instance though JMX using jconsole to see how it behaves
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.
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.