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).
Related
Is using JSP Hot deployment a solution to publish new or updated content to avoid restarting the Java EE server (cannot hot deploy jar)? I should not use JSP to code a lot of java, but do I have any other solution?
With Tomcat, you can use the Parallel Deployment method. You will be able to deploy your new version and keep older one running with every users that has a session on it.
It is really simple when you are using WAR files, I recommend a simple script to delete older versions after couple of days for exemple, just to keep only few running versions.
You can get more informations here : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
Did you have a look at JRebel yet?
I am facing a very weird problem. This is one of those errors that just doesn't make sense. Please read till the end before jumping to conclusions.
When I deploy our web application (.ear file) containing web services written in Apache CXF on JBoss without making any changes to the web.xml file, everything seems to work fine.
When I make some changes to the web.xml file and rebuild the ear and redeploy the application, JBoss is unable to deploy my application because of some class loader conflicts. This is completely alright because I am expecting JBoss to throw these errors.
After I stop the JBoss server instance and revert the changes made in Step 2 to the web.xml and rebuild my .ear file and redeploy the application in JBoss, the same errors that were thrown in Step 2 are thrown again. How is this possible considering that I reverted all the changes I had made to the web.xml in Step 2 and restarted JBoss with a fresh .ear file to use?
I even tried downloading a fresh copy of JBoss and rebuilding and redeploying the application on the fresh copy. The same errors that were displayed in Step 2 are displayed in the application even though the web.xml no longer contains the changes that were made in step 2.
The only way I am able to get rid of the errors is by taking a fresh checkout of my code base and building my application and deploying a fresh version of my application in a fresh JBoss server. This doesn't make sense because changing the web.xml doesn't implicitly change other files or classes in the application as far as my knowledge goes.
I am clueless about how to solve this problem. The only change I make is to the web.xml file and I don't touch any other classes or files. Why do the errors persist permanently?
This time before you start your JBoss server, delete tmp and work folders under the server profile directory. That should take care of it.
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
I have several webapps deployed to production. I have used Tomcat as my servlet engine for ~10 years now. I'm considering moving to embedding Jetty model from the deploy-a-war-into-Tomcat model.
These webapps are deployed over several servers and some of the are horizontally scaled (using nginx IP hash based partitioning).
I see some advantages:
I can configure my servlet engine for a particular webapp (instead of having a generic configuration for Tomcat which is running several different webapps)
It's easier to horizontally scale my webapp by running multiple Jetty instances (configured to listen on different ports) on the same host. I could also do this with Tomcat (and I have run multiple tomcat instance on the same host in the past), but I've moved to using Debian packages (.deb archives) for deployment and it's not as easy to run multiple Tomcats using this method.
My deployment package (.deb) is more "complete" at build time i.e. I don't have to be sure the Tomcat instance is configured correctly.
And disadvantages:
More instances of a servlet engine running on a server means more resources being used
I've never used Jetty. I don't think I have any Tomcat-specific stuff going on in my webapps, but I'm not sure.
My main concern is the amount of resources that Jetty will use. If I had one Tomcat instance running 4 webapps, what will the difference in resources (memory/processor) be with four Jetty instances running?
This question is probably too open-ended, but I'm curious to know if I'm overlooking something or if anybody has any experience moving from Tomcat to (embedded) Jetty.
The web container I've found easiest to embed in a jar file (and it is still a valid WAR too) is Winstone (http://winstone.sourceforge.net/).
Jenkins - http://jenkins-ci.org/ - use this container so it has been pretty stress-tested. Note that it is Servlet 2.4 only.
Well I think there is no direct answer;
I might not fully understand the ".deb" part as I'm not a debian freak :)
I prefer having an instance of tomcat with a number of configurations aka CATALINA_HOME folders where you may specify apps and ports running, so you can always have all your configs separately and change the tomcat instance if needed.
Also, see related post:
Jetty: To embed or not to embed?
I also was used to Tomcat, so in my new project I tried using Jetty to learn about it.
In an enterprise environment (where you have production / testing / development servers) I would stick to Tomcat, mainly because it helps you in getting to separate code from configuration files (now I am working in setting the conf files in a separate jar, because that way when I move changes from testing to production they do not have to manually update the jars that I'll pass to sysadmin).
Other issue is that it looks like that Jetty has changed ownership not so long ago, and looking for info often got me to the old version.
Apart from that, using Jetty is not that different from Tomcat; had to run a little through docs for finding where everything is, but structure is (as last what I have seen, I have not tried anything too complicated) more or less like Tomcat.
I'm about to use MySQL with Hibernate on a Tomcat 5.5.x server.
Do I have to put mysql-connector-java-[version]-bin.jar in $CATALINA_HOME/common/lib/ or could I place it in WEB-INF/lib inside my WAR file with my other library dependencies?
It would be easier to have it in my WAR in WEB-INF/lib, as I could get it using the Maven repository that way. Are there any big draw backs to having it there instead of in the common libraries directory of Tomcat?
If your jar is in common then it's loaded globally in tomcat. Every webapp sees it. If you put it in your webapp only your webapp sees it. What I assume Boris is referring to is if some part of your global tomcat config loads something that needs a mysql connection (like a connection pool) then it's going to need the jdbc driver, so it'll need it in common. Otherwise, no.
I believe there's a security configuration you can set up in the tomcat config that stores its config in a db. If you use this, it'll need a driver.
Why would you want stuff in webapp/WEB-INF/lib? well, because it's modular, it's part of your webapp, if you move your webapp somewhere else it doesn't need an extra part of it that's part of your tomcat installation. Maintenance is much easier if you can drop your webapp directly in a stock tomcat installation. Another reason- if you have multiple webapps, they're all going to use the jars in common, which could cause library conflicts and version issues.
In general, put as little in common as you can get away with. Even if you only have a single app.