TransactionPortalCache isn't limited regarding size

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, 7.1.X, 7.2.X, 7.3.X, Master
• Fix Version/s: 7.0.0 DXP FP102, 7.0.10.16 DXP SP17, 7.0.X, 7.1.10 DXP FP26, 7.1.10.7 SP7, 7.1.X, 7.2.10 DXP FP15, 7.2.X, 7.3.10.3 DXP SP3, 7.3.X, 7.4.13 DXP GA1, 7.4.3.13 CE GA13, 7.4.3.14 CE GA14, 7.4.3.15 CE GA15, Master
• Component/s: Performance > Caching Infrastructure
• Labels:
  • ee-ts
  • liferay-dxp-70-sp17
  • liferay-dxp-71-sp7
  • liferay-dxp-73-sp3
  • liferay-fix-pack-dxp-3-7310
  • liferay-fixpack-de-102-7010
  • liferay-fixpack-dxp-15-7210
  • liferay-fixpack-dxp-26-7110
  • liferay-fixpack-dxp-3-7310
  • marketplace-saml-5.0.3-7210
• Branch Version/s:
  7.3.x, 7.2.x, 7.1.x, 7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 3
• Git Pull Request: i4)GrtG&sByw$cYnNtU8

TransactionalPortalCacheUtil doesn't have any size restrictions in the transaction scope. UncommitedBuffer accepts an unlimited number of elements as long as the transaction hasn't been committed.

 

Steps to Reproduce:

1. Create a huge number of events using the provided script: AuditEventCreate.groovy
2. Retrieve that number of events using the provided script: OutOfMemory.groovy

 

Expected Results:

Memory should not be exhausted with the default cache maxElementsInMemory sizing.

 

Actual Results:

An OutOfMemoryError is obtained if the number of events created/retrieved is big enough.

 

To reproduce it could be needed to increment the amount variable in the creation script. Also, it can be reproduced executing a heap dump in the middle of the iteration script and check that the TransactionalPortalCache is one of the top consumers.