Status: Verified (View Workflow)
Affects Version/s: 7.3.2.GA, 7.1.6.GA, 7.2.9.GA
Steps to Reproduce:
Configure the WildFly to set the timeout to 0
Call a EJB remote call from WFLY to WFLY. Check the heap dump to see that there is hanging SubordinateXAResource stored in the Narayana TransactionImple from concurrent hash map at JBossLocalTransactionProvider#known. And it's removed only after one year.Configure the WildFly to set the timeout to 0 /subsystem=transactions:write-attribute(name= default -timeout, value=0) Call a EJB remote call from WFLY to WFLY. Check the heap dump to see that there is hanging SubordinateXAResource stored in the Narayana TransactionImple from concurrent hash map at JBossLocalTransactionProvider#known . And it's removed only after one year.
Git Pull Request:
Release Notes Docs Status:Not Yet Documented
QE Test Coverage:+
When WFTC creates transaction it stores it under a Map to know about active in-flight transactions. That way it may commit it or say that the transaction with the id is unknown to the transaction manager.
The WFTC stores the memory mapped in-flight transactions in BossLocalTransactionProvider#known map.
if the transaction is finished (committed/rolled-back) - ie. the LocalTransaction#commit is called - the map is cleaned immediately with the call to (owner.getProvider().dropLocal(...), https://github.com/wildfly/wildfly-transaction-client/blob/1.1.12.Final/src/main/java/org/wildfly/transaction/client/LocalTransaction.java#L64).
But the immediate cleaning happens only when the transaction does not contain the outflowed resoure (aka. remote EJB enlistment) - see https://github.com/wildfly/wildfly-transaction-client/blob/1.1.12.Final/src/main/java/org/wildfly/transaction/client/LocalTransaction.java#L62
When transaction contains the outflowed transaction then the cleanup happens only during afterCompletion callback - https://github.com/wildfly/wildfly-transaction-client/blob/1.1.12.Final/src/main/java/org/wildfly/transaction/client/provider/jboss/JBossLocalTransactionProvider.java#L230
which happens at time of transaction timeout + staleTransactionTime.
This is needed as the transaction with outflowed enlistments need to be active for a while after its finished as it may be renewed by transaction recovery.
If the transaction timeout is set for a long time (e.g. in WildFly if default timeout is set to 0 then the WFTC global transaction timeout is set to maximum timeout which equals to one year
then the memory mapped transaction is removed only after that long time - aka. after 1 year. That may cause big consumption of memory and issues for GC.
The lifetime of the finished transaction with remote enlistment should be limited only to staleTransactionTimeout.
if it does then the removal does not happen and is processed only by afterCompletion callback (JBossLocalTransactionProvider#getEntryFor->registerInterposedSynchronization)