[
https://issues.apache.org/jira/browse/JS2-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568326#action_12568326
]
Vitaly Baranovsky commented on JS2-852:
---------------------------------------
The same problem is with tomcat. By default, tomcat contains minSpareThreads=25
and maxSpareThreads=75. So, thread pool contains from 25 up to 75 threads. So,
there is very big memory overuse after some time of portal working. For
example, our site is hanging for 5-10 minutes for about every 40 minutes. At
this time garbage collector tries to free TenuredGen without any success.
I've maken memory time at the moment of this hanging, and I see many
ContentFragmentImpl inside ThreadWithAttributes, and it uses very much of
memory...
I think, workaround is setting minSpareThreads=0 maxSpareThreads=0 for tomcat,
and people that uses jetspeed have to wait next jetspeed release. I've asked
question about this in tomcat mailing list:
http://www.nabble.com/Will-be-any-problem-if-I-set-minSpareThreads%3D0-maxSpareThreads%3D0-to15443784.html
Is there a simple way to fix this issue in source code of jetspeed 2.1.3?
> 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]
