Search code examples
weblogic-10.xweblogic11g

Weblogic deployment issue


We have the following situation on our weblogic10.2 environment.

The managed nodes seem to be extracting an older cached version of the deployed war on start.
They simply ignore the newer version of the deployable copied over to the deployment location on the admin server.

We are unable to locate where from do the managed nodes retrieve this cached version of the deployable(war file).
This happens even if the admin server is kept down.

Any pointers on how to diagnose this situation ;and unearth where the cached version is residing would be appreciated.


Solution

  • Weblogic reads the deployment from the staged folder, assuming you deployed it using defaults. It is probably reading this staged copy, as it can't read the correct source (turning the admin server off would also probably do this, since the correct deployment would be on the admin server). You can change how weblogic deploys the ear/war files when you are performing the deployment- using either staging or no-stage. Also, when you deploy a new version, are you using Update rather than remove the old copy? If not, weblogic supports Updating as you as you place version information into the Manifest.mf file. This then lets you Update in place, which should fix any caching issues. It also allows you to gracefully switch the deployment, and view the current state (both can be running- the old copy until all old sessions die, and the new one for all new sessions). Once the old sessions have ended, weblogic retires the old copy. If you just drop new copies in, weblogic might still hang on to some resources until it is cleaned up- such as any links in the JNDI tree. That might cause some issues.