I am currently using tomcat 6 as my Web Server. I have a very small application which should not take long to deploy on server, but my tomcat is taking too long start.
It is taking most of its time in following step.
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
I don't know why it is taking much time. Same is the case with stopping the server. I tried almost everything I know. I also tried to delete server from the workspace and started from scratch. I don't know what is the problem.
You can find out which library consumes the time. When the server is being started in a debug mode, pause its thread several times and examine stacktraces. There may be possibly some library that populates its Spring application context, weaves advised objects, initializes file storage, whatever. If so, you will see it from stacktraces.
Have you removed all the default web applications that comes with the tomcat installation ?
Even though your webapp is a small one, there might be other applications that are taking time to be installed. You can check this from the server log files with the name catalina___.log files.
I know this post is old, even i wanted to share few check points on this because these are irrespective of tomcat version...
I was facing the same issue and i followed below steps and now my server is starting with in 130 ms.
First verify the console if you are using any IDE, there you can find time in milliseconds for each application. So you will come to know which one is taking long time.
To make sure, your finding is correct just remove that app from 'webapps' folder and start tomcat again.
Remove the default applications which you don't need. Usually we only use tomcat manager, so just keep manager app and remove other applications from 'webapps' folder
Make sure 'temp' folder is empty
Clean up the older log files. And don't write your application log files in server folder.
Start the server first and deploy the file later. So that you don't face timeout error.
This is what i tried any succeed.
Possibly this is due to a lack of availability of random entropy, which Tomcat requires.
See https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource
and
Slow startup on Tomcat 7.0.57 because of SecureRandom
(Edit: first link updated)
I guess you have placed all your libraries (JARs) in the WEB-INF/lib folder. Instead move those to a separate directory and refer the directory or JARs using shared.loader in the catalina.properties
Related
We have been using tomcat 7.0.19 successfully in embedded mode. However recently due to some fixes in our area of concern we decided to move to tomcat 7.0.32. Most things work as expected with same code and newer version, however the war deployment for some reason has'nt worked well. I have a couple of servlets registered with my tomcat. Facing below 2 issues,
Has something changed from 7.0.19 to 7.0.32 from embedded tomcat behavior. To detail this out let me explain the behavior difference, with 7.0.19, i could deploy my application and when i hit the "host:port/contextpath" it loaded the applications start page (i.e. welcome page, this page is UI centric and does not need a server intervention, so none of my servlets get called). However with 7.0.32 the same url results in my servlet being called.
So to debug the problem, i commented most of my code so that i have a vanilla tomcat implementation, just the very basic stuff, i.e. setting the engine name, default host, setting host properties, adding a connector (nio, with default properties) and deploying a war. No servlets and other things, just to check if the very basic stuff works. To my surprise when i ran this code it still failed with the same problem within my servlet, how did that happen, now that my code is commented it does not register any servlets, still where does it find it from? Does embedded tomcat store some old references, which are not getting cleaned on subsequent runs? I tried changing the port, but that too didn't help.
I am hitting the wall here, not able to understand this wierd behavior, if i figure out #2, only then can i make some progress on #1.
Thanks in advance,
Vikram
Figured out what the problems were.
In reverse order,
2 - This actually was a weird behavior with the vanilla embedded tomcat code too invoking the servlets which never were registered in the first place. The problem here was with eclipse, for some reason it picked up the old reference of my class. The moment i ran the same code from outside of eclipse i.e. via command prompt, things were back to normal.
1 - This problem was related to web deployment, in my code i was additionally setting my classloader into WebappLoader and eventually adding my application jars into it. This for whatever reasons worked fine with 7.0.19, however did not with 7.0.32, the moment i externalized all my jars to be loaded during application startup via classpath this problem too was resolved.
Thanks,
Vicky
Whenever, WL is stopped it doesn't delete its temporary directories .. i.e.
domains/mydomain/servers/myserver/tmp/_WL_TEMP_APP_DOWNLOADS
/domains/mydomain/servers/myserver/tmp/_WL_user/
/domains/mydomain/servers/myserver/stage
and because of this, when we deploy new application, it doesn't deploy some JSP or some classes and it keeps the old version of those files. resulting in lots of business errors + runtime error.
Is it a known issue ? How can we tackle it?
In general WL will cache your deployment and won't redeploy unless it is asked to. But it depends on how you deployed your application and if the server is in production or development mode. See development deployments and production deployments.
One easy fix, go to the /domains/mydomain/servers/myserver/ directory and delete:
tmp
cache
logs
and leave the data and security directory. Then restart. This will force WL to redeploy.
My original answer included a delete of the data directory but as #g-demecki and #j23 point out below, that can mess up an admin server. I believe it is OK to delete the data directory on a managed server.
I never run into such issue in production mode, if you are running in development mode and using auto deploy, please follow best practices documented
You must touch the REDEPLOY file (alter its timestamp) any time you
wish to trigger redeployment of an auto-deployed application. Even if
you modify an application while a server is shut down, you must touch
REDEPLOY to ensure that changes are applied when the server next
starts up.
Redeploy should update the tmp - maybe your timestamps are not ok ?
Stop and start will not refresh tmp as it is still used after restart.
From my experience it is enough to delete tmp when server is down to force unpack WAR (it is a matter of unpacking WAR to tmp by Weblogic, this is the main task done during deployment).
e.g. in your case
/domains/mydomain/servers/myserver/tmp/
In my case, a simple reboot of the Linux machine fixed the issue.
We just discovered that every time we restart JBoss, all of our Java Web Start clients redownload all of their jars, instead of reusing the cached jars, even if our application has not changed.
From what I've seen on the web, Java Web Start does an HTTP HEAD to decide whether or not to download a jar. So I ran HTTP HEAD on all jars in our application, and discovered that after restarting JBoss, the modified time of all the jars has changed!
Why is this, and how can I fix it? The jars inside of my application archives have not changed at all. As near as I can tell, JBoss uses the time of startup or time of deploy as the modified time. This is going to completely short-circuit Java Web Start's ability to use cached jars from previous runs, if I understand correctly.
We use JBoss 6, if that's an issue. Previously we used JBoss 4. I want to check to see if we had the problem under JBoss 4, but we now have so many dependencies on the newer JBoss that it is going to take some work to make that test happen.
Try deploying your application as an exploded web application instead of a WAR file.
That would prevent JBoss having to decompress the application and potentially mess up the modification dates.
You'll have to handle updates to your app in a way that preserves modification dates, e.g., rsync, but that might be easier than downgrading or patching JBoss.
It looks like VFSUtils isn't maintaining the lastModifiedDate of the file when it mounts the filesystem to the tmp directory on server startup. You could patch the copy methods in that class to try to set the timestamp of the new file based on the values from the physical file.
As a response to the comment by chubbard: the problem does not occur with Tomcat (tomcat 7.0.21 to be precise).
There is an issue (https://issues.jboss.org/browse/JBVFS-177) created about the VFSUtils.unzip() which does not preserve timestamps while deploying (still applicable to JBoss 6.1).
As the issue is related to the unzip method the solution of blahdiblah may indeed works.
Another way would be to use Java Web Start with a version based (Modification of the jnlp with versionEnabled and creation of a version.xml).
I know the answer to this, but I'm posting this here because as an app developer, I was burned by this problem several times and it took a very long time to find the answer:
I've moved my glassfish installation dir, and now it hangs on startup.
How can I fix this?
There are a couple strategies that you can apply to resolve this issue.
The quick and dirty 'solution' is to
Make sure the server is stopped.
Delete the content of the
osgi-cache, by removing the
osgi-cache/felix directory in your
domain. This is usually found in
glassfishv3/glassfish/domains/domain1
(GlassFish Server 3.0.1) OR
glassfish3/glassfish/domains/domain1
(GlassFish Server 3.1).
There are situations where this will damage your domain, since you can install OSGi modules into your server that do not come from the glassfish/modules directory. To avoid this kind of problem, you may want to
Verify that the server is stopped
Apply this work-around.
To give credit, the answer comes from this thread.
Here is the executive summary, and what you need to do:
I think you need to delete the existing OSGi framework cache, since the
framework uses the location of the bundles as a key and moving the
install directory thus changes this key. You should just be able to delete:
glassfish-v3/glassfish/domains/domain1/osgi-cache/felix/
This question already has an answer here:
Using special auto start servlet to initialize on startup and share application data
(1 answer)
Closed 7 years ago.
We have a few war files deployed inside an ear file. Some of the war files have a class that caches static data from our PLM system in singletons. Since some of the classes take several minutes to load we use the load-on-startup in the web.xml to load them ahead of time. This all works fine until we attempt to re-deploy the application on our production servers. (WebLogic 10.3) We get an exception from our PLM API about a dll already being loaded. Our PLM vendor has confirmed that this is a problem and stated that they don't support using the load-on-startup. This is also a huge problem on our development boxes where we have redeploy the app all the time. Most of us, when we're not working on one of the apps that uses a cache, have them commented out. Obviously we can't do that for the production servers. Right now we transfer the ear to the production server, deploy it in the console, wait for it to crash, shut the app server instance down and then start it up again.
We need to find a way around this...
One suggestion was to create a servlet that we can call after the server boots that will load the various caches. While this will work I'm looking for something a bit cleaner. Is there anyway to detect once the server started and then fire off the methods?
Thanks.
We had a similar problem with a third party JDBC driver that loaded a native DLL. When redeploying the app the driver would crash saying the DLL was already loaded. The solution (if one can call it that) was to move the driver from deploy into lib. This way the driver was global to the app server and didn't need to be reloaded when the app was redeployed.
What about using a servlet container lifecycle listener, such as ServletContextListener?
Example on how to use.
EDIT: Sorry, after re-reading your question I don't think this will work. You want something that will load only once per server life, not application life. The ServletContextListener's methods will be called each time the app is deployed, just like a load-on-startup servlet (which it seems you are using). My suggestion will do the exact same thing in a different way.
I would try Chris Nava's suggestion.
EDIT2: It looks like tomcat has some lifecycle listener(s) available to it also. It looks like documentation is sparse, but this potentially would allow you to do something on server startup specifically only once.
EDIT3: Yes, a tomcat lifecycle listener is the way to go. This link explains pretty well how to set one up. Should be fairly straight forward. If you ignore the part about adding the Transaction to tomcat, it goes over pretty thoroughly how to add a lifecycle listener.