Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Later
-
Adobe Flex SDK 3.0 (Release)
-
None
-
None
-
Affected OS(s): All OS Platforms
Affected OS(s): All OS Platforms
Language Found: English
Description
This is bug http://frpbugapp.macromedia.com/bugapp/edit.asp?ID=193307 being transfered into Jira:
In summary, the web-tier compiler does not release the jars under WEB-INF/flex/jars when its containing web-app is undeployed on a server that allows undeployment without server stop - WebLogic or WebSphere.
Details:
Once access to the war application which is deployed on the staging mode on
Weblogic Server 90 or Tomcat, Flex2 can not undeploy the war application.
It seems to keep to access the FDS file.
Reproduction:
WLS90
1. deploy samples.war on the staging mode
2. access to samples
3. undeploy samples.war
4. the following file remains
Ex: C:\bea\user_projects\domains\test02\servers\AdminServer\stage\samples\samples.war\WEB-INF\flex\jars
5. Can not delete the above file
(With Flex-admin, MessageBroker of samples.war is displayed)
Tomcat
1. Deploy samples.war on Tomcat using Application Manager
2. Access to samples and see mxml
3. Using Application Manager, stop samples
4. Undeploy samples
5. jar files are not deleted under the directory like ...webapps\samples\WEB-INF
6. When deploy samples again, need to restart Tomcat
Actual Results:
<2006/12/13 11:48:03 JST> <Warning> <Deployer> <BEA-149258> <Server failed t
o remove the staged files 'C:\bea\weblogic91\samples\domains\wl_server\.\servers
\examplesServer\stage\test\test' for application 'test' completely. Check the di
rectory and make sure no other application using this directory. This will resul
t in inappropriate results when this server gets partitioned and trying to deplo
y this application.>
Expected Results:
Workaround:
Shutdown/Restart Application Server every time for WLS90
For Tomcat, set <Context path="/sample" antiJARLocking="true"> in context.xml
[yasukawa 12/12/06] Entered Bug.
[jhernand 1/10/07] Sending to QRB
[trbaker 1/16/07] Open to Ed.
[wwechten 3/12/07] Deferring and adding related bug.
[wwechten 3/12/07] Oops, wrong comment. Still deferred. Ed, if you have a fix for this go ahead and check it in. Otherwise we'll leave for later.
[esolovey 3/12/07] The issue seems to be that our BootstrapClassLoader does not get garbage collected and therefore all of the jars that it has touched remain locked. The antiJARLocking="true" flag on tomcat simply makes a copy of the jars, it does not prevent the ClassLoader from not being garbage collected.
Blog for reference,
http://blog.exis.com/colin/archives/2005/08/23/i-put-a-spell-on-you-because-youre-mine-aka-why-is-tomcat-holding-onto-jars/
I tried adding a destroy method to BoostrapClassLoader:
public void destroy()
{
this.classCache.clear();
this.classCache = null;
BootstrapClassLoader.instance = null;
}
and calling it from the destroy method of BoostrapServlet, but nulling out those references did not resolve the problem. A memory profile tool such as OptimizeIt would be useful here to see what is hanging on to our class loaders and preventing them from being garbage collected. Do we have access to any memory profile tools?
[wwechten 3/14/07] We'll find the right tools post-Borneo and look into it again. Re-deferring.
[wwechten 7/23/07] Reopen for opportunistic fix.