portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-226) Page Aggregation using STRATEGY_PARALLEL severly broken
Date Thu, 31 Aug 2006 03:19:25 GMT
    [ http://issues.apache.org/jira/browse/JS2-226?page=comments#action_12431771 ] 
David Sean Taylor commented on JS2-226:

Hi Woonsan,

I was planning on working on the parallel strategy in September for the 2.1 release. My schedule
has slipped a little though, so Im encouraged to hear someone else show interest in the parallel

I wouldn't be put off by the performance.
There are some very valuable use cases that make the parallel strategy valuable. If all of
your portlets are simply retrieving small snippets of content, and displaying them, there
will be no advantage. In fact, the overhead will make the overall aggregation slower. I would
think that we would want to make use of hints to help with the parallel aggregation process,
such as statistical analysis and configuration. With configuration, a portlet can be marked
as requiring parallel. With statistics, we can keep track of which portlets are slow, and
move those into thread groups based on their historical performance.

The key use case for parallel rendering is when one or more portlets are taking a lot longer
than other portlets to render, then the other portlets will not have to wait on them as they
do in the sequential strategy. Additionally, we can put a ms threshold on all portlet threads
returning, so that if a portlet takes more than say 4000 ms, we override  the content with
"Portlet Not Available" and return the entire response stream. The thread will have to be
collected later. 

I think your idea, of storing attributes in the worker, is sound.
In my testing, I also discovered that Tomcat requests are not thread-safe.

We are actually solving this problem from two different approaches in 2.1. Parallel rendering
on the server is on approach. The second approach is parallel rendering on the client, with
the Jetspeed Desktop.
The Desktop solution distributes the aggregation process onto clients. 

Anyway, I'd be very happy to work with you on this.

> Page Aggregation using STRATEGY_PARALLEL severly broken
> -------------------------------------------------------
>                 Key: JS2-226
>                 URL: http://issues.apache.org/jira/browse/JS2-226
>             Project: Jetspeed 2
>          Issue Type: Bug
>          Components: Aggregation
>    Affects Versions: 2.1
>         Environment: Tomcat 5.0.28
>            Reporter: Ate Douma
>         Assigned To: David Sean Taylor
>            Priority: Critical
> While trying to evaluate the status of JS2-17 I tested PageAggregation with PageAggregatorImpl.STRATEGY_PARALLEL
and the effect is a total breakdown!
> I'll look into this AFTER the M2 release.
> Not sure if the current problem is related to JS2-17 but I'll check that too.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message