You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by David Dyer <dd...@artifact-software.com> on 2010/03/02 23:49:37 UTC
Setting a portlets timeout value
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.
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.
Another page refresh returns the portlet.
At one millisecond, shouldn't the portlet fail everytime?
David
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Setting a portlets timeout value
Posted by David Sean Taylor <d....@onehippo.com>.
On Tue, Mar 2, 2010 at 2:49 PM, David Dyer <dd...@artifact-software.com>wrote:
> 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.
>
> 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.
>
> Another page refresh returns the portlet.
>
> At one millisecond, shouldn't the portlet fail everytime?
>
> Make sure your portlet isn't cached. Also, could you try putting a 500 ms
delay in your doView
Re: Setting a portlets timeout value
Posted by Woonsan Ko <wo...@yahoo.com>.
--- On Wed, 3/3/10, Ron Wheeler <rw...@artifact-software.com> wrote:
> From: Ron Wheeler <rw...@artifact-software.com>
> Subject: Re: Setting a portlets timeout value
> To: "Jetspeed Users List" <je...@portals.apache.org>
> Date: Wednesday, March 3, 2010, 2:01 PM
> Woonsan Ko wrote:
> > Hi David,
> >
> > --- On Tue, 3/2/10, David Dyer <dd...@artifact-software.com>
> wrote:
> >
> >
> >> From: David Dyer <dd...@artifact-software.com>
> >> Subject: Setting a portlets timeout value
> >> To: "Jetspeed Users List" <je...@portals.apache.org>
> >> 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: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Setting a portlets timeout value
Posted by Ron Wheeler <rw...@artifact-software.com>.
Woonsan Ko wrote:
> Hi David,
>
> --- On Tue, 3/2/10, David Dyer <dd...@artifact-software.com> wrote:
>
>
>> From: David Dyer <dd...@artifact-software.com>
>> Subject: Setting a portlets timeout value
>> To: "Jetspeed Users List" <je...@portals.apache.org>
>> 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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Setting a portlets timeout value
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi David,
--- On Tue, 3/2/10, David Dyer <dd...@artifact-software.com> wrote:
> From: David Dyer <dd...@artifact-software.com>
> Subject: Setting a portlets timeout value
> To: "Jetspeed Users List" <je...@portals.apache.org>
> 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: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org