JM-1251 fixes a similar memory leak, but introduces a new one. The method checkForTimedOutUsers() in MultiUserChatServerImpl will never iterate over more than one value of the 'users' collection, if USER_IDLE equals -1. This is caused by the 'return' statement inside the if-loop. Fix: change 'return' to 'continue' Impact: without the fix, we had 78,886 instances of LocalMUCUsers, while we believed to have approximately 250 actual users in chatrooms. JProfiler reports around 160MB of 'exclusive deep size' (which should be an indication of the amount of memory that is eligable for garbage collection if the instances were to be removed). Workaround: you can workaround by setting the property 'xmpp.muc.tasks.user.idle'. As MultiUSerChatServerImpl is NOT a PropertyChangeListener, you need to do this through the muc-tasks.jsp admin panel page, instead of setting a property manually (or restart Openfire after you set the property). For other properties that are used in MultiUserChatServerImpl, a similar issue occurs. As some of these properties cannot be changed indirectly through an admin panel, changing these properties will require an Openfire restart. Perhaps the class should listen for property changes instead?