Created attachment 25306 [details] Unit test illustrating the problem Server.stop() should unregister all MBeans registered by Tomcat but it is not the case. It has side effects when starting a new Server as some Tomcat components like MapperListener components rely on what they find in the MBeanServer and try to work with objects that don't exist anymore (like Host for MapperListener) Provided unit test shows a part of the problem (in fact the helper class Tomcat should be improved to register all MBeans just like a "normal" Tomcat distribution). A workaround consists in cleaning up the JMX tree from all Catalina objects once server.stop() has been called. For info: it seems that such a problem has already been reported: bug #47046
For info: same problem exists with Tomcat 6
The unit test highlights issues when the default domain name of Catalina is not used. This should get addresses in the wider clean up that is planned for MBean registration as part of the next stage of Lifecycle refactoring.
I'm about half way through the MBean/Lifecycle re-factoring and this issue is now fixed. I tweaked the provided unit test a little to: - ensure there are no Cataina mbeans - a sufficient number of Tomcat MBeans (20) get created - that all the Tomcat MBeans get cleaned up on tomcat.destroy() Clean-up is not expected on a stop() as components may get re-started.
With tomcat 7.0.42 Catalina.stop() doesn't unregister all MBeans registered by Catalina.start() for example : - Catalina:type=Realm,realmPath=/realm0/realm0 - Catalina:type=RequestProcessor* As there is no Catalina.destroy() what should I do ?
I've fixed the realm MBean issues in 7.0.x and 8.0.x (the CombinedRealm wasn't destroying nested Realms). I'll look at the RequestProcessor MBeans next.
I can't reproduce the RequestProcessor issue. Please provide the simplest possible test case to reproduce - ideally as a patch to the existing unit test. See http://svn.apache.org/r1529546 and http://svn.apache.org/r1529549 for some examples of extending that test case.
A month has gone by with no further information provided. The issue I could repeat has been fixed in trunk and 7.0.x so I am resolving this as fixed.