[ https://issues.jboss.org/browse/JBRULES-3559?page=com.atlassian.jira.plug... ] Fabio Strozzi updated JBRULES-3559: ----------------------------------- Steps to Reproduce: See attached test application -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3559?page=com.atlassian.jira.plug... ] Fabio Strozzi edited comment on JBRULES-3559 at 7/10/12 11:21 AM: ------------------------------------------------------------------ Hi, I have some updates about the problems I reported. There're two main issues involved here, some of which may have been fixed in Drools 5.4: # a memory leakage happens when transaction management is done in a Oracle Weblogic 10.3 application server and no transaction manager is esplicitly set in the knowledge-base environment. # even if I can get around the first issue by esplicitly set a transaction manager, another memory leakage happens due to an event listener being registered twice when a persisted knowledge session is loaded while being removed only once when the session is disposed (read ahead for the details). In order to fix issue #1 class org.drools.persistence.jta.JtaTransactionManager must be changed as follows: # a new value has to be inserted into array FALLBACK_TRANSACTION_MANAGER_NAMES in order to support the naming convention of Oracle Weblogic 10.3: {code} public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = new String[]{"java:comp/TransactionManager", "java:appserver/TransactionManager", "java:pm/TransactionManager", "java:/TransactionManager", "javax.transaction.TransactionManager"}; {code} # method findTransactionSynchronizationRegistry has to be fixed by changing these lines {code} InitialContext context = new InitialContext(); context.lookup(jndiName); logger.debug("JTA TransactionSynchronizationRegistry found at default JNDI location [{}]", jndiName); return tsr; {code} into these {code} InitialContext context = new InitialContext(); Object tsr = context.lookup(jndiName); logger.debug("JTA TransactionSynchronizationRegistry found at default JNDI location [{}]", jndiName); return tsr; {code} # moreover, if no transaction manager or transaction sysnchronizionation register were found, then there's no need to update the synchronization map. A potential fix may be obtained by changing method registerTransactionSynchronization of JtaTransactionManager as follows: {code} public boolean registerTransactionSynchronization(final TransactionSynchronization ts) { if ( this.tsr != null ) { TransactionSynchronizationRegistryHelper.registerTransactionSynchronization(this.tsr, ts); return true; } else if (this.tm != null) { try { this.tm.getTransaction().registerSynchronization(new JtaTransactionSynchronizationAdapter(ts)); return true; } catch (Exception e) { // No JTA TransactionManager available - log a warning. logger.warn("Participating in existing JTA transaction, but no JTA TransactionManager or TransactionSychronizationRegistry available: ", e); } } else { // No JTA TransactionManager available - log a warning. logger.warn("Participating in existing JTA transaction, but no JTA TransactionManager or TransactionSychronizationRegistry available: "); } return false; } {code} Also, method registerRollbackSync of class SingleSessionCommandService must be changed accordingly {code} private void registerRollbackSync() { if ( synchronizations.get( this ) == null ) { if (txm.registerTransactionSynchronization( new SynchronizationImpl( this ) )) synchronizations.put( this, this ); } } {code} Concerning issue #2, the memory leakage is due to this method {code}InputMarshaller.readSession(MarshallerReaderContext context, int id, ExecutorService executor, Environment environment, SessionConfiguration config){code} when it performs the following steps: {code} ReteooStatefulSession session = new ReteooStatefulSession( id, context.ruleBase, executor, handleFactory, initialFactHandle, propagationCounter, config, agenda, environment ); session.setKnowledgeRuntime( new StatefulKnowledgeSessionImpl( session ) ); {code} The constructor of StatefulKnowledgeSessionImpl sets the knowledge runtime once again; this in turn instances a new ProcessRuntimeImpl class which adds an event listener by using method initProcessEventListeners. Whenever a new listener is added twice (see method addEventListener of KnowledgeBaseImpl) a new KnowledgeBaseEventListenerWrapper object is created and then it's added to the list ruleBase; also, the listener is added to the hashmap called mappedKnowledgeBaseListeners. Problem comes because if addEventListener is called more than one time for the same listener, then the map will contain only one reference to the listener while the ruleBase list will contain two references to two different wrappers. This becomes clear when the dispose method of ProcessRuntimeImpl is called and the listener is removed from the knowledge base: every time this happens, only one wrapper is removed from the ruleBase list hence causing the leakage. I'm attaching two test apps that prove this fact: application AppOk always instantiates a new session while AppKo loads an existing session. One possible fix could be to rewrite the readSession method as done with Drools 5.4: {code} ReteooStatefulSession session = new ReteooStatefulSession( id, context.ruleBase, executor, handleFactory, initialFactHandle, propagationCounter, config, agenda, environment ); new StatefulKnowledgeSessionImpl( session ) ; {code} Even if issue #2 has been fixed in Drools 5.4, I cannot manage to update to this version of the library as it would need several regression tests on my application. In order to fix issue #1 is it safe to fix the JtaTransactionManager the way I described? In order to avoid the memory leakage associated to issue #2, do you think it's reasonable not to load sessions but always creating new ones? Could this cause performance problems for instance? Given that version 5.3.0 Final was a stable release, do you think a bug-fix release can be expected? Regards Fabio was (Author: f.strozzi): Hi, I have some updates about the problems I reported. There're two main issues involved here, some of which may have been fixed in Drools 5.4: # a memory leakage happens when transaction management is done in a Oracle Weblogic 10.3 application server and no transaction manager is esplicitly set in the knowledge-base environment. # even if I can get around the first issue by esplicitly set a transaction manager, another memory leakage happens due to an event listener being registered twice when a persisted knowledge session is loaded while being removed only once when the session is disposed (read ahead for the details). In order to fix issue #1 class org.drools.persistence.jta.JtaTransactionManager must be changed as follows: # a new value has to be inserted into array FALLBACK_TRANSACTION_MANAGER_NAMES in order to support the naming convention of Oracle Weblogic 10.3: {code} public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = new String[]{"java:comp/TransactionManager", "java:appserver/TransactionManager", "java:pm/TransactionManager", "java:/TransactionManager", "javax.transaction.TransactionManager"}; {code} # method findTransactionSynchronizationRegistry has to be fixed by changing these lines {code} InitialContext context = new InitialContext(); context.lookup(jndiName); logger.debug("JTA TransactionSynchronizationRegistry found at default JNDI location [{}]", jndiName); return tsr; {code} into these {code} InitialContext context = new InitialContext(); Object tsr = context.lookup(jndiName); logger.debug("JTA TransactionSynchronizationRegistry found at default JNDI location [{}]", jndiName); return tsr; {code} # moreover, if no transaction manager or transaction sysnchronizionation register were found, then there's no need to update the synchronization map. A potential fix may be obtained by changing method registerTransactionSynchronization of JtaTransactionManager as follows: {code} public boolean registerTransactionSynchronization(final TransactionSynchronization ts) { if ( this.tsr != null ) { TransactionSynchronizationRegistryHelper.registerTransactionSynchronization(this.tsr, ts); return true; } else if (this.tm != null) { try { this.tm.getTransaction().registerSynchronization(new JtaTransactionSynchronizationAdapter(ts)); return true; } catch (Exception e) { // No JTA TransactionManager available - log a warning. logger.warn("Participating in existing JTA transaction, but no JTA TransactionManager or TransactionSychronizationRegistry available: ", e); } } else { // No JTA TransactionManager available - log a warning. logger.warn("Participating in existing JTA transaction, but no JTA TransactionManager or TransactionSychronizationRegistry available: "); } return false; } {code} Also, method registerRollbackSync of class SingleSessionCommandService must be changed accordingly {code} private void registerRollbackSync() { if ( synchronizations.get( this ) == null ) { if (txm.registerTransactionSynchronization( new SynchronizationImpl( this ) )) synchronizations.put( this, this ); } } {code} Concerning issue #2, the memory leakage is due to this method {code}InputMarshaller.readSession(MarshallerReaderContext context, int id, ExecutorService executor, Environment environment, SessionConfiguration config){code} when it performs the following steps: {code} ReteooStatefulSession session = new ReteooStatefulSession( id, context.ruleBase, executor, handleFactory, initialFactHandle, propagationCounter, config, agenda, environment ); session.setKnowledgeRuntime( new StatefulKnowledgeSessionImpl( session ) ); {code} The constructor of StatefulKnowledgeSessionImpl sets the knowledge runtime once again; this in turn instances a new ProcessRuntimeImpl class which adds an event listener by using method initProcessEventListeners. Whenever a new listener is added twice (see method addEventListener of KnowledgeBaseImpl) a new KnowledgeBaseEventListenerWrapper object is created and then it's added to the list ruleBase; also, the listener is added to the hashmap called mappedKnowledgeBaseListeners. Problem comes because if addEventListener is called more than one time for the same listener, then the map will contain only one reference to the listener while the ruleBase list will contain two references to two different wrappers. This becomes clear when the dispose method of ProcessRuntimeImpl is called and the listener is removed from the knowledge base: every time this happens, only one wrapper is removed from the ruleBase list hence causing the leakage. I'm attaching two test apps that prove this fact: application AppOk always instantiates a new session while AppKo loads an existing session. One possible fix could be to rewrite the readSession method as done with Drools 5.4: {code} ReteooStatefulSession session = new ReteooStatefulSession( id, context.ruleBase, executor, handleFactory, initialFactHandle, propagationCounter, config, agenda, environment ); new StatefulKnowledgeSessionImpl( session ) ; {code} Even if issue #2 has been fixed in Drools 5.4, I cannot manage to update to this version of the library as it would need several regression tests on my application. In order to fix issue #1 is it safe to fix the JtaTransactionManager the way I described? In order to avoid the memory leakage associated to issue #2, do you think it's reasonable not to load sessions but always creating new ones? Could this cause performance problems for instance? Regards Fabio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira