[
https://issues.apache.org/jira/browse/JS2-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sean Taylor resolved JS2-852.
-----------------------------------
Resolution: Fixed
We have done some extensive testing over the last month on this. Using the IBM
Heap Analyzer, I am not seeing this leak anymore
> Release content buffers after rendering
> ---------------------------------------
>
> Key: JS2-852
> URL: https://issues.apache.org/jira/browse/JS2-852
> Project: Jetspeed 2
> Issue Type: Improvement
> Components: Aggregation
> Affects Versions: 2.2
> Reporter: David Sean Taylor
> Assignee: David Sean Taylor
> Fix For: 2.2
>
>
> With a heap analysis tool, we have discovered that, when using a ThreadPool,
> such as on WAS 6.1, thread locals are being held onto for long periods of
> time.
> In the PortletEntityImpl, we are using a ThreadLocal to associate per user
> content fragments with the current thread, as the entity object is not user
> specific and thus not content specific.
> Instead of putting FragmentPortletDefinition directly on the thread local,
> instead put it on the Request Context request attribute map (which is really
> the servlet container's request attribute map)
> Thus, the FragmentPortletDefinition, and all objects in its subtree, most
> notably ContentFragmentImpl, PortletContentImpl, and PortletContentImpl's
> stream of content, will all be put into true per request storage, and no
> longer stick to the pooled thread locals.
> As an additional improvement, we will add logic to release the PortletContent
> streams after completion of draining of buffered streams out to the servlet
> response stream.
> I also want to investigate stream pooling properly at this time
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
