[
https://issues.apache.org/jira/browse/PLUTO-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Piper updated PLUTO-569:
-----------------------------
Attachment: patch.txt
PlutoIssueTestCase.zip
Zip file containing test portlets and a test case - this hits a page called
"mark", which needs to be set up beforehand with the 3 portlets present on it.
The test case simply loops, and hopefully you'll see the NPE's appear every now
and again in the Pluto logs.
Also attached is our patch.
> Threading issue in DefaulltPortletInvoker
> -----------------------------------------
>
> Key: PLUTO-569
> URL: https://issues.apache.org/jira/browse/PLUTO-569
> Project: Pluto
> Issue Type: Bug
> Components: portal driver
> Affects Versions: 2.0.0
> Reporter: Mark Piper
> Attachments: patch.txt, PlutoIssueTestCase.zip
>
>
> A portlet application with multiple portlets registered to listen for the
> same event often falls over with NPE exceptions in PortletServlet.dispatch()
> (line 308), caused by the PortletRequest not being set in the ServletRequest.
> On investigation, the issue appears to be that the DefaultPortletInvoker is
> sharing the containerRequest object across event-firing threads, and the
> invoking block is not synchronised. That is, event thread 1 adds the
> PortletRequest to the ServletRequest, does it's work, and then removes the
> PortletRequest. Meanwhile, event thread 2 is in the middle of doing it's
> work, but thread 1 has just removed the PortletRequest attribute.
> Zip file with portlets and test case demonstrating the issue (it occurs on
> about 40-50% of requests on an Intel Xeon 2.4Ghz, 2Gb RAM on Win XP) will be
> attached, along with patch to simply synchronize the relevant block on the
> ServletRequest object in DefaultPortletInvokerService.invoke().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
