[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Scott Marlow updated ISPN-771: ------------------------------ Fix Version/s: 4.2.0.CR1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Manik Surtani commented on ISPN-771: ------------------------------------ The check isn't a guard, it is how you select which listener to remove. When you call AbstractListenerImpl.removeListener(), https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... gets a collection of *all* listeners registered under a particular annotation. The check in https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... just ensures we remove the correct listener. When an AS application is deployed/undeployed, is the cache restarted? Because if it is, AbstractListenerImpl.stop() should be called which should clear all registered listeners. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Scott Marlow updated ISPN-771: ------------------------------ Attachment: all-clleak-simple.sh the all-clleak-simple.sh is attached and can be run from the AS development tree root after starting an AS instance (ALL profile). The attached script only loops twice but can easily be changed to loop multiple times. I saw the OOM after running the script for a few hours on Saturday. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Paul Ferraro updated ISPN-771: ------------------------------ Attachment: patch.txt When an app is undeployed, the backing cache is stopped, but its cache manager is not (the cache manager is shared across all apps). Consequently, TransactionTable is not removing it's ViewChanged listener (that was added in start()) on stop(). The attached patch to TransactionTable makes start() and stop() symmetrical. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Scott Marlow commented on ISPN-771: ----------------------------------- The patch worked for my test. Thanks! :) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-771?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreño updated ISPN-771: ---------------------------------- Fix Version/s: 4.2.0.Final Affects Version/s: 4.2.0.BETA1 4.1.0.Final 4.0.0.Final Description: org.infinispan.notifications.AbstractListenerImpl.listenersMap has a org.infinispan.notifications.cachemanagerlistener.annotation.ViewChanged that is always increasing number of entries (per deploy/undeploy with AS) [0]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [1]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [2]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [3]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [4]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [N]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup keeps increasing until we run out of memory Looks like we miss removing these because: org.infinispan.notifications.AbstractListenerImpl.removeListenerInvocation private void removeListenerInvocation(Class<? extends Annotation> annotation, Object listener) { if (listener == null) return; List<ListenerInvocation> l = getListenerCollectionForAnnotation(annotation); Set<Object> markedForRemoval = new HashSet<Object>(); for (ListenerInvocation li : l) { if (listener.equals(li.target)) markedForRemoval.add(li); // NEVER EQUALS } l.removeAll(markedForRemoval); } listener = org.jboss.web.tomcat.service.session.distributedcache.ispn.DefaultLockManagerSource@1d2d2db8 0:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@2eedd32f 1:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@18b9ae20 2:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@226d7ba7 ... same li.target class for all entries, so they don't get removed class org.jboss.web.tomcat.service.session.distributedcache.ispn.DefaultLockManagerSource implements LockManagerSource class org.infinispan.transaction.xa.TransactionTable.StaleTransactionCleanup is a pojo with onViewChange method. was: org.infinispan.notifications.AbstractListenerImpl.listenersMap has a org.infinispan.notifications.cachemanagerlistener.annotation.ViewChanged that is always increasing number of entries (per deploy/undeploy with AS) [0]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [1]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [2]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [3]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [4]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup [N]org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.target = org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup keeps increasing until we run out of memory Looks like we miss removing these because: org.infinispan.notifications.AbstractListenerImpl.removeListenerInvocation private void removeListenerInvocation(Class<? extends Annotation> annotation, Object listener) { if (listener == null) return; List<ListenerInvocation> l = getListenerCollectionForAnnotation(annotation); Set<Object> markedForRemoval = new HashSet<Object>(); for (ListenerInvocation li : l) { if (listener.equals(li.target)) markedForRemoval.add(li); // NEVER EQUALS } l.removeAll(markedForRemoval); } listener = org.jboss.web.tomcat.service.session.distributedcache.ispn.DefaultLockManagerSource@1d2d2db8 0:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@2eedd32f 1:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@18b9ae20 2:li.target=org.infinispan.transaction.xa.TransactionTable$StaleTransactionCleanup@226d7ba7 ... same li.target class for all entries, so they don't get removed class org.jboss.web.tomcat.service.session.distributedcache.ispn.DefaultLockManagerSource implements LockManagerSource class org.infinispan.transaction.xa.TransactionTable.StaleTransactionCleanup is a pojo with onViewChange method. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira