• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009


The attached patch stops the rmiregistry in RMICacheManagerPeerListener if it was started by ehcache.

This fixes a classloader leak for web applications. The classloader leak persists if ehcache and backport-util-concurrent are in the WAR and not in common/lib of tomcat, though. Maybe this could be documented in the UserGuide.

If you have any question regarding this patch feel free to ask.

Sourceforge Ticket ID: 1728780 - Opened By: fleiter - 31 May 2007 07:55 UTC


Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO


Ok, added the patch. You must be one of the few people on the planet who knows how to stop an RMIRegistry. I did a Google search and read through the first few pages of links. No-one has mentioned this. It is not in the JavaDoc. There are lots of people who want to know the answer. Amazing. A close reading of the createRegistry javadoc says it exports it. But because the implementation is in Sun code, you cannot see whether any other magic happens. Anyway thanks for this, and for finally answering the question on stopping an RMIRegistry.

I have added a note to the Tomcat chapter in the manual. This is the second case where reloading or redeploying requires ehcache to be in the common/lib directory.

The change is in trunk and will be in ehcache-1.3.0.

Greg Comment by: gregluck - 2 Jun 2007 00:40 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira