Affects Version/s: 5.2.3
Fix Version/s: None
Component/s: Core Infrastructure
There seems to be a multi-threading issue that can cause Liferay to sometimes display the incorrect view when multiple requests are served simultaneously on the same session.
I noticed the problem when I configured a couple of bookmarks in a folder in Firefox and then told Firefox to open both bookmarks at the same time. Both bookmarks went to the same Liferay page. However, one bookmark had query string parameters that targeted a specify portlet on that page ... the other bookmark was simply to the page itself. This should have resulted in two different versions of the page being displayed in the two new tabs opened by Firefox. However, what actually happened was that both tabs showed the same version of the page. The tab that referenced the bookmark directly to the Liferay page (with no query string) showed the incorrect view ... it showed the same view as the tab with the URL with the query string parameters.
The problem appears to be timing related. I could not reproduce it every time ... but fairly often. I will upload a JMeter script that I also used to reproduce the problem (though you won't be able to use it directly as it references my custom pages/portlets).
After a bit of testing and digging it appears that the problem only occurs if the multiple requests occur in rapid succession and use the same JSESSIONID (for an existing session). This would of course be the case when Firefox opens the multiple tabs at once.
From looking at the code, I suspect that the problem has to do with the PortletRequestImpl. This class appears to store render parameters in the session ... mapped the plid. However, if multiple requests are processed at the same time ... there doesn't seem to be anything to prevent the parameters for one thread/request from being overwritten by those of another thread/request.
So, I suspect that what may happen is something like this:
- request 1 comes in for the default page ... and resets the parameters in the session and then blocks
- request 2 comes in with portlet parameters and stores the parameters in the session
- request 1 thread resumes ... sees that the request is not targeted to a portlet and therefore retrieves the parameters from the session ... but these are actually the parameters for request 1 not request 2 (hence the bug)