[WSRP4J-106] Concurrency issue in UserSession handling. A UserSessionImpl may be created wrapping the wrong user PortletSession.

• Type: Bug
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: current (nightly)
• Component/s: Proxy Portlet
• Assignee: Unassigned
• Reporter: Steve Etherington
• Created: 16/Mar/09 11:10
• Updated: 16/Mar/09 11:10

Description

A UserSessionImpl may be created wrapping the wrong user PortletSession.

The ProxyPortlet obtains a UserSession from the SessionHandlerImpl singleton. The ProxyPortlet sets the current PortletSession in the SessionHandlerImpl and then calls getUserSession. The SessionHandlerImpl returns a new UserSessionImpl which wraps the PortletSession reference it holds. This happens in a synchronized block, which prevents a portlet in one thread overwriting the PortletSession before the UserSessionImpl is obtained.

// code from ProxyPortlet.getWindowSession
// now we can get our sessions
UserSession userSession = null;
synchronized(sessionHdlrLock)

{ SessionHandler sessionHandler = (SessionHandler)consumerEnv.getSessionHandler(); sessionHandler.setPortletSession(request.getPortletSession()); // get the user session userSession = sessionHandler.getUserSession( portletKey.getProducerId(), userID); }

However, the SessionHandlerImpl is also used within the PortletDriverImpl. In this case the getUserSession method is called without first setting the PortletSession. If the call to PortletDriver.getMarkup or performBlockingInteraction, or releaseSessions happens in a different thread from the call to setPortletSession, then the PortletDriverImpl may get hold of a UserSessionImpl wrapping the wrong PortletSession.

// code from PortletDriverImpl.checkInitCookie - unsynchronized, no PortletSession set.
UserSessionMgr userSession = this.consumerEnv.getSessionHandler().getUserSession(
getPortlet().getPortletKey().getProducerId(), userID);

One possible problem is that the PortletDriver may use the wrong markup ports.

Note that if the differing threads correspond to the same PortletSession, or if the different sessions refer to portlets from the same producer, then an error may not be apparent. Only if there is an unlucky timing in an environment with multiple concurrent users, to portlets with different producers is an error likely to become apparent. In other words this problem is likely to show in some Production environments but not in most test environments.

I have fixed the problem locally by creating the UserSessionImpl once per thread from within the ProxyPortlet and passing the UserSessionImpl to the getMarkup, etc methods on my own PortletDriver variant. This also removes the need for the (anyway insufficient) synchronized block and sessionHdlrLock.

Compare with WSRP4J-87, which invlolved similar issues and similar possible resolutions.