--- On Wed, 3/3/10, Ron Wheeler <[email protected]> wrote:
> From: Ron Wheeler <[email protected]> > Subject: Re: Setting a portlets timeout value > To: "Jetspeed Users List" <[email protected]> > Date: Wednesday, March 3, 2010, 2:01 PM > Woonsan Ko wrote: > > 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 > > > > > > Perhaps we are overly focused on the timeout. > We do not know if this is the cause of the behaviour. > The main supporting fact of this is the apparent randomness > of the > behaviour. > > Is there any other explanation of this? > > Is it a "good thing" to have 2 browser windows talking to > Jetspeed at once. > > What if the Tomahawk widget makes a request to the portal > to refresh its > view.? > Will Jetspeed try to dispatch a second request to the > portlet or kill > the original portlet requests before it completes Jetspeed doesn't do anything on managing the lifecycle of each http request. It's managed by the servlet container. Jetspeed just processes every request when the servlet container invokes Jetspeed servlet. > > > Is there a better way to have a Jetspeed portlet open new > window onto a > foreign site while retaining its own session in the > original window? Sounds like session/cookie handling in a general web application. AFAIK, there's no best practice for that. Furthermore, there could be some risky situations. Anyway, I think you could search on internet for a technique on how to keep session alive in a web page. Regards, Woonsan > We just want to send a person off to take a course > somewhere else and > have them back in their portal when they close thte > window. > > > --------------------------------------------------------------------- > 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]
