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 strategy.
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.