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.
Related
Even if we enable "deploy on save" with our IDE, we still need to wait some time to propagate changes. This can be annoying espacially when we deploy small changes.
So, is it possible to run some servlet container in-memory with IDE-compatible deployment to speed up deployment and development time? Or even run whole container in-memory with server dependencies (JSP compilator etc.).
(I know that I can install Tomcat on RAMDisk, but looking for "more native" solution)
According from their site
JRebel is a JVM-plugin that makes it possible for Java developers to instantly see any code change made to an app without redeploying. JRebel lets you see code changes instantly, versioning classes and resources individually and updating one at a time instead of as a lump application redeploy. When developers make a change to any class or resource in their IDE, the change is immediately reflected in the deployed application, skipping the build and redeploy phases and preventing an average of 5.25 work weeks per year in redeploys!
http://zeroturnaround.com/software/jrebel/
The first thing you can do is to set the deployment path to your webapps directory. This way you deploy the application "exploded" without copying the whole app to another deployment directory. Make sure to let the classes be compiled into the WEB-INF/classes directory.
A second, more problematic thing is, the class loader. When the JVM runs in debug mode, some code changes made within methods will be recognized by the class loader and you would see the changes immediately. But some changes, like method signature and structural class changes will not be detected, so a restart of the JVM will be necessary. You can provide a self brewed class loader which will be able to reload anything when the underlying class files changes.
The tomcat container is loaded in memory when you start it. And tomcat loads all the applications available in webapps directory. Later as and when application classes are required are loaded. And application may load some other resources as required.
If you open the task manager on windows or similar thing on other OS, you can see that tomcat java process is always runnning once started. You may also check its current memory footprint . So it is not unloaded and re-loaded on demand.
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
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/
Environment: WinXP.
RAD: Version: 7.5.3 (Eclipse 3.4.2)
Websphere 6.1
I have two web projects on my local RAD environment and 4 or 5 sub jar projects. When I change classes in debug and regular start mode, the files don't get copied to the server for runtime.
So, normally I have to restart the server completely or add/remove the project all together.
I may make a change to Servlet.java
When I do "publish", the ear/application seems to restart, but my changes are not there. So I normally restart the server. This is a productivity killer.
Additional settings:
* Publish automatically turned off.
* Minimize resources. Use workspace.
What can I do to make sure that the classes get copied over.
My theories:
I have parent_first/application for the class loader/war settings. Is that an issue?
Maybe I should remove the ear and add it back to websphere
I did a clean on the server?
Delete your application from the server.
Restart the server
Go to the admin console and ensure the application is not listed in the list of applications, if it is then delete it.
Restart the server
Deploy/publish again.
Unfortunatelly, RAD with WebSphere are very unstable environment.
From my experience, debug mode is causing a lot of problems. It's mainly what you describe, changes not being seen after republish, additionally very quick memory depletion. I'm using debug mode as last report.
In normal mode everything should (read: in most cases) work correctly. You add/change some classes and make 'republish'. Sometimes it's necessary to do clean on project before republishing it.
But when the Websphere is running longer together with RAD, I observe that often something get stuck. You have there clean option on the server, with is expected to clean the cache (which included also compiled classes). You should also observe memory usage. If it's nearing the limits of JVM (memory leaks are heavy) Websphere stops to function correctly, and you must restart it.
However, I sometimes get serious issues where the clean isn't helping, and then it's necessary to remove all applications, stop the websphere (close all projects and open then again) and then start Websphere and add all applications, restarting RAD in the meanwhile. But it's not everyday, maybe every month or so...
If you are really unlucky, RAD can break your workspace, which will force you to delete all project, delete project files (or do a fresh checkout) and import everything once again, or even start a new workspace (happens also with 'normal' Eclipse, ~1-2 years).
You are using the latest RAD so do I... here is my guide for solving this issue:
Enable the error log to see if you get intuitive info on internal RAD errors, in 7.5 it is available on "Show views"
If your changes are not deployed Clean project
If your changes are not deployed yet Rebuild project
If your changes are not deployed yet Redeploy project
If your changes are not deployed yet Clean server
If your changes are not deployed yet Restart server
Or:
- Use ant or maven to make deployments straighforward and ignore the pain due to websphere and eclipse having internal bugs (which you may see in the error log if it is fully enabled).
Regards.
Are your JSPs copied correctly? That is, when you make a change in one JSP, can you see change immediately upon browser refresh? If this works, then I see no reason why classes aren't also published. JSP auto refresh should work in normal and debug modes.
Now, is "build automatically" enabled? If no, your classes won't get compiled and transferred. Parent_first/application for class loading shouldn't be an issue.
Is the local app. server running in development mode? If not, it should be.
While developing, use debug mode. Hot deploy will assure changes to your methods are seen immediately. Changes in classes won't be seen (i.e. adding a method will require application restart).
Is your app. server using global security? I have it turned off and auto redeploy works without problems.
Class reloading has always been a problem while developing Java EE applications. Try do erase that ear file from your WAS and redeploy it again.
If all else fails, try JRebel.