WSRP proxy portlet generating incorrect URLs for concurrent requests to different consumers in Liferay 5.2.3

• Type: Bug
• Status: Closed
• Resolution: Won't Fix
• Affects Version/s: 5.2.3
• Fix Version/s: 6.0.6 GA, 6.1.1 CE GA2, 6.2.0 CE M2
• Component/s: Portal Services, Portal Services > Component Management, Portal Services > Component Management > Hot Deployment, WSRP
• Labels: None
• Environment: Liferay Portal 5.2.3 as WSRP consumer, JBoss Portal as WSRP producer (but does not appear to depend on which producer is used). Multiple WSRP proxy portlets on separate pages connecting to different WSRP producers.

This issue might not apply to Liferay 6.x series (I was not able to find the corresponding WSRP code in 6.0 or 6.1 sources). However, reporting it anyway with a patch in case it affects version 6 too or if anyone still using 5.2.3 needs a fix for it. The same issue was also present in Liferay 4.4.2.

Feel free to mark as won't fix if this does not apply to 6.x series.

Issue:
When there are concurrent incoming requests to two or more WSRP proxy portlets connecting to different WSRP producers, occasionally URLs generated by WSRP portlet A point to WSRP portlet B or vice versa. This causes users to be shown incorrect views or unexpected errors as producer B ends up receiving a request originally meant for producer A.

How to reproduce:
1. Set up two WSRP producers A and B producing different content.
2. Publish WSRP proxy portlets A and B connecting to producers A and B, respectively.
(we have them published on different pages but I don't think it matters)
3. Set up two or more paraller web tester instances (we have used Selenium) to access different WSRP portlets in a loop, "clicking" generated URLs and verifying whether the returned content comes from the right WSRP producer.
4. Eventually tester accessing WSRP portlet A gets content generated by WSRP producer B.

Cause:
com.liferay.portlet.wsrp.WSRPProxyPortlet method _renderRemote() uses a shared static URLTemplateConsumer (obtained via _consumerEnv.getTemplateComposer()) for all requests. However, the obtained shared URLTemplateConsumer is initialized by calling URLTemplateConsumer.setURLGenerator() with a request specific URLGenerator instance at the beginning of each request. When there are concurrent requests, the URLGenerator being used to process an earlier request might change before the request is completely processed because a later requests reconfigures the shared URLTemplateConsumer.

Fix:
A simple fix would be to extend the synchronized block in _renderRemote() to cover the processing of a whole request. However, this would have a severe negative impact on performance because requests could not be processed in parallel. Attached patch modifies the code to pass URLGenerator as a parameter to underlying code instead of initializing URLTemplateConsumer with it. This patch fixes the problem for us in 5.2.3 (and also did for 4.4.2). However, it requires changes to classes in oasis.names and org.apache packages so it is just a quick fix. A more proper fix would probably be to modify Liferay code so that it would not use shared URLTemplateConsumer for different requests but I remember running into some issues while working on this.