Hi David, --- On Tue, 3/2/10, David Dyer <[email protected]> wrote:
> From: David Dyer <[email protected]> > Subject: Setting a portlets timeout value > To: "Jetspeed Users List" <[email protected]> > Date: Tuesday, March 2, 2010, 11:49 PM > Jetspeed 2.1.3/tomcat5.5.27 > > I've run into an interesting issue. I have a portlet that > contains a tomahawk datatable of links. When a user clicks > on one of the links the browser opens a new window, with an > address of javascript:void(0), this is in turn interpreted > as /http://myhost/myportal/undefined/ > and waits to catch the response from the portlet response. > > The portlet's ( who's portlet class is > org.apache.portals.bridges.jsf.FacesPortlet ) process action > is run in turn calling our own code, which does some lookups > in our database, and does a single sign on to a third > party. > > We do an insert in their database, create a url and > redirect the ActionResponse to the created url wich is > returned to the targetted popup. > > Most of the time everything works as expected but > occasionally the popup window ends up returning the same > page as the original (the default-page.psml for the user). > There are no errors or exceptions being thrown. > > My suspision is that the portlet response is timing out > before the redirect occurs. In an effort to test this theory > I've been trying to reset the timeout on the portlet as > described here: > > http://portals.apache.org/jetspeed-2/deployguide/guide-aggregation.html > > I've tried resetting the timeout value in the > jetspeed-portlets.xml to 1 millisecond to force the portal > to timeout, however the portlet still renders and the popup > link behaviour remains the same, mostly working but failing > occasionally. Tomcat is restarted when I change the timeout > value. Timeout does not happen during the action phase. It could happen only in the rendering phase. If your portlet does some work in processAction(), then the work would never be interrupted. After processing action on a portlet, the page would be redirected to the same page to render portlets. Timeout could happen in this rendering phase. And, the timeout metadata in jetspeed-portlet.xml could be applied only when the page aggregator of aggregation valve is set to AsyncPageNavigator, as explained in the "Changing the Page Aggregator to Multithreaded" section. By default, it's not enabled. Also, if the portlet's cache expiration is set to -1 or any positive value, then the portlet would never be rendered in the aggregator until a the cache is expired. By the way, you can check if it's really interrupted due to timeout by inspecting warning logs because Jetspeed leaves a log line for that as follows: log.warn("Portlet Rendering job to be interrupted by timeout (" + job.getTimeout() + "ms): " + windowId); > > Once it has failed once, it seems to repeat the same > behavior until a shift+refresh in the browser. After several > failures the PortletTrackingManager deactivates the portlet > and writes its message to the page. Yes, if there are multiple consecutive failures, the PortletTrackingManager takes the portlet ouf of service. This is configured in aggregation.xml. The default consecutive times is 3. > > Another page refresh returns the portlet. > > At one millisecond, shouldn't the portlet fail everytime? Not necessarily. The worker monitor of async page aggregator checks its workers periodically (every second). It tries to interrupt the worker if the rendering job of the worker is exceeding the timeout limit. So, even though the timeout is 1 millisec., if the portlet is already rendered within the first monitoring interval, the monitor doesn't have to interrupt the worker. Also, the interrupt trial from the worker monitor depends on java.lang.Thread#interrupt(). If a worker thread contains another thread which ignores the interruption or is too busy, then that invocation could be ignored or delayed. Kind regards, Woonsan > > David > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
