portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vitaly Baranovsky (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-852) Release content buffers after rendering
Date Tue, 12 Feb 2008 21:49:08 GMT

    [ 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message