CXF locking jars in Tomcat when undeployed preventing hot deployment / eating
up permgen
----------------------------------------------------------------------------------------
Key: CXF-2286
URL: https://issues.apache.org/jira/browse/CXF-2286
Project: CXF
Issue Type: Bug
Affects Versions: 2.2.2
Environment: Tomcat 6, Java 1.6, Windows+Linux
Reporter: Jerome Waibel
Create a simple webapp with the following in web.xml:
<servlet>
<display-name>CXF Servlet</display-name>
<servlet-name>CXFServlet</servlet-name>
<servlet-class>
org.apache.cxf.transport.servlet.CXFServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>CXFServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
No fancy code, no real web services, just plain starting of the servlet. Create
a war and deploy it into a tomcat. Enjoy the startup of the servlet. Press
"undeploy" in the tomcat application manager.
Under windows you will notice that most of the cxf jars are *not* deleted in
the webapps directory, the application isn't completly undeployed. Tomcat seems
to lock the jars preventing them from beeing deleted. Subsequent re-deployment
of the webapp will fail because of the left-over jars. Hot re-deployment of the
webapp is impossible.
Under linux the webapp directory is gone, but this is because linux' ext
filesystem allow files beeing deleted that are still held open by an
applicaton. When checking with the lsof tool you will see that under linux
tomcat still has references to the old jar. Hot re-deployment is possible here,
but you will soon run out of permgen memory because the old classes are not
unloaded.
It seems the servlet is still locking some kind of resource when undeployed
(thus preventing tomcat from beeing able to close and delete the jars). Maybe
the destroy method lacks some important cleanup.
This bug is there at least since CXF 2.1.2 and still in 2.2.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.