There are multiple SharedSessionWrappers pointing to the same portlet session in PortletSessionTracker

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.1.0 CE GA1, 6.1.10 EE GA1, 6.2.0 CE M2
• Fix Version/s: 6.0.X EE, 6.1.20 EE GA2, --Sprint 11/12, 6.2.0 CE M2
• Component/s: Core Infrastructure, Performance
• Labels: None
• Branch Version/s:
  6.1.x, 6.0.x
• Backported to Branch:
  Committed
• Git Pull Request: https://github.com/liferay/liferay-portal/pull/227

For deployed portlets, upon each request, PortletServlet tries to add the portlet session wrapped in a SharedSessionWrapper to PortletSessionTracker so that we can invalidate the session when the HTTP session gets invalidated. However as we wrap the portlet session into a new SharedSessionWrapper for each getSession() request and because SharedSessionWrapper doesn't have its hashCode() or equals() method implemented, the hash set in PortletSessionTracker will store this new SharedSessionWrapper for each request.

While this usually doesn't cause any out of memory problems as users' sessions time out and real load on a portal usually involves multiple sessions, there can be scenarios when many requests are sent either in a relatively short time or with a long lived session (load test, single - e.g. machine - consumer on the other end). In these cases this problem can cause out of memory errors.