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
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?
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]
