Affects Version/s: 6.1.X EE, 6.2.X EE
Fix Version/s: None
Component/s: Core Infrastructure
Please note this is very hard to reproduce and doesn't occur in every environment. The test case described here was conducted with the customer's data in a similar environment like theirs.
Method PortletRequestUtil.toXML() serializes the actual portlet request to XML, which happens indirectely when a web content is displayed. While a user is browsing throught a portal with many pages and with many Web Content Displays, their session is growing ever larger, because method SessionAuthToken.getToken(HttpServletRequest, long, String) is persisting new LIFERAY_SHARED_AUTHENTICATION_TOKEN##PLID##LAYOUT##PORTLETID## = ##RANDOMSTRING## attributes into the session for every unique (plid, portletId) pair.
When PortletRequestUtil.toXML() gets executed the resulting XML will contain many of the following element as children of application-attributes.
Consequently, due to the fact that large strings are allocated frequently, under load, the system is seeing increased GC activity.
During testing, I captured the output of requestElement.toXMLString() at the end of method toXML(). before.xml and after.xml denotes the contents of the resulting XML respectively for the same use case before and after the fix.
Notes for QA
- Measuring the GC overhead isn't directly possible, because we cannot replay that workload the customer has.
- I used the customer's data, but you can use a vanilla Liferay with ~10 pages with ~10 Web Content Displays on each
- After visiting each page, the contents of requestElement.toXMLString() can be observed with a debugger.
- When the fix is applied the value of requestElement.toXMLString() should be significantly smaller.
- This is a 6.x only issue, on Master
LPS-45558eliminates the unnecessary XML serialization overhead.