Hello!

I need someone with some historical knowledge of Pluto to help me out with this one.

For some reason, portlets that we have using portlet-mvc 2.0.1 or spring-webmvc-portlet 2.5.6 using uPortal 2.5.3.2 with Pluto 1.0.1 have shown the following behavior:

It seems that when the handleRenderRequestInternal method completes quickly, then the following happens (this example log fragment was from a portlet using spring-webmvc-portlet 2.5.6):

[CODE]DEBUG [Thread-366] Nov/04 10:57:16,917 portlet.DispatcherPortlet.[] - DispatcherPortlet with name 'fooportlet' received render request DEBUG [Thread-366] Nov/04 10:57:16,917 portlet.DispatcherPortlet.[] - Bound render request context to thread: org.apache.pluto.core.impl.renderrequesti...@7f556a0e DEBUG [Thread-366] Nov/04 10:57:16,917 portlet.DispatcherPortlet.[] - Testing handler map [org.springframework.web.portlet.handler.portletmodehandlermapp...@6703d837] in DispatcherPortlet with name 'fooportlet' DEBUG [Thread-366] Nov/04 10:57:16,918 handler.PortletModeHandlerMapping.[] - Key [view] -> handler [edu.acme.fooportlet.controller.fooportletcontrol...@957ba31] DEBUG [Thread-366] Nov/04 10:57:16,918 portlet.DispatcherPortlet.[] - Testing handler adapter [org.springframework.web.portlet.mvc.simplecontrollerhandleradap...@2d6837b7] DEBUG [Thread-366] Nov/04 10:57:16,918 controller.FooPortletController.[] - Request for fooportlet DEBUG [Thread-366] Nov/04 10:57:16,918 controller.FooPortletController.[] - Got feed for 'http://acme.edu/feed' containing 10 entries. DEBUG [Thread-366] Nov/04 10:57:16,918 portlet.DispatcherPortlet.[] - Setting portlet response content type to view-determined type [text/html;charset=ISO-8859-1] DEBUG [Thread-366] Nov/04 10:57:16,919 view.JstlView.[] - Added model object 'somemodel' of type [java.util.RandomAccessSubList] to request in view with name 'view' DEBUG [Thread-366] Nov/04 10:57:16,919 view.JstlView.[] - Added model object 'anothermodel' of type [java.util.RandomAccessSubList] to request in view with name 'view' DEBUG [Thread-366] Nov/04 10:57:16,920 view.JstlView.[] - Including resource [/WEB-INF/jsp/view.jsp] in InternalResourceView 'view' DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] - JspEngine --> /barportlet/* DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] - ServletPath: /barportlet DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] - PathInfo: /* DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] - RealPath: /path/to/tomcat/webapps/fooportlet/barportlet/* DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] - RequestURI: /barportlet/barportlet/* DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] - QueryString: null DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] - Request Params: DEBUG [Thread-366] Nov/04 10:57:16,921 portlet.DispatcherPortlet.[] - Cleared thread-bound render request context: org.apache.pluto.core.impl.renderrequesti...@7f556a0e DEBUG [Thread-366] Nov/04 10:57:16,921 portlet.DispatcherPortlet.[] - Successfully completed request[/CODE]

In this example FooPortlet is the portlet being rendered, but for some reason you can see that JspServlet is mixing some stuff up and using the BarPortlet's view.

We didn't notice this until I made changes to the controller code within the FooPortlet so that the handleRenderRequestInternal method returned very quickly.

I was able to remedy this by adding a Thread.sleep(800) to the end of the handleRenderRequestInternal method, but then noticed (as we had before) that this issue was still occurring intermittently in other portlets (specifically I noticed another one that is using portlet-mvc 2.0.1).

If this was an issue in Pluto at some point, perhaps it was fixed long ago. If anyone remembers it, could you point me to a Jira ticket or any related documentation? I'm having a hard time finding anything for it. Or maybe someone could provide the right class and possibly the method that might be problematic, and maybe I could just patch pluto 1.0.1. I don't think later versions of Pluto work with uPortal 2.5.3.2, and we don't have the ability to upgrade at the moment, so anything you can share about this would help. I've grepped through the code myself, but I think I'd probably make progress faster if someone could help.

Thanks!

Gary

Reply via email to