You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "David Sean Taylor (JIRA)" <je...@portals.apache.org> on 2008/04/15 00:43:04 UTC

[jira] Created: (JS2-864) Release render buffers (PortletContent) after rendering

Release render buffers (PortletContent) after rendering
-------------------------------------------------------

                 Key: JS2-864
                 URL: https://issues.apache.org/jira/browse/JS2-864
             Project: Jetspeed 2
          Issue Type: Improvement
          Components: Aggregation
    Affects Versions: 2.2
            Reporter: David Sean Taylor
            Assignee: David Sean Taylor
             Fix For: 2.2


When rendering with thousands of users, we are seeing large buffers being left in memory and not released.
When Java goes to garbage collect, the buffers are not being release due to references to these buffers being held. This is described in JS2-800. Combining this fix with JS2-800 should enable the garbage collector to properly free up these per request buffers.

Looking at heap dump, we can see:

1,308,968,904 (81%) [40] 4 org/apache/jetspeed/container/window/impl/PortletWindowAccessorImpl 0x5a459e98
 1,308,968,864 (81%) [48] 4 java/util/Collections$SynchronizedMap 0x5a459ee8
  1,308,968,752 (81%) [64] 3 java/util/HashMap 0x5a459eb8
   1,308,968,688 (81%) [81,320] 20,326 array of java/util/HashMap$Entry 0xaf52a080


The above problem is addressed in JS2-800, where we can limit the number of PortletWindows in memory
Combined with too many portlet windows in memory, the portlet content render buffers are held on to, and never released.
This bug fix aids the garbage collection algorithm by "releasing" the buffers upon render completion
Note I have seen some very large buffers held on to and never released.
By setting the streams to null, we can try to aid the garbage collection into freeing these buffers


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


[jira] Resolved: (JS2-864) Release render buffers (PortletContent) after rendering

Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
     [ https://issues.apache.org/jira/browse/JS2-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Sean Taylor resolved JS2-864.
-----------------------------------

    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 render buffers (PortletContent) after rendering
> -------------------------------------------------------
>
>                 Key: JS2-864
>                 URL: https://issues.apache.org/jira/browse/JS2-864
>             Project: Jetspeed 2
>          Issue Type: Improvement
>          Components: Aggregation
>    Affects Versions: 2.2
>            Reporter: David Sean Taylor
>            Assignee: David Sean Taylor
>             Fix For: 2.2
>
>
> When rendering with thousands of users, we are seeing large buffers being left in memory and not released.
> When Java goes to garbage collect, the buffers are not being release due to references to these buffers being held. This is described in JS2-800. Combining this fix with JS2-800 should enable the garbage collector to properly free up these per request buffers.
> Looking at heap dump, we can see:
> 1,308,968,904 (81%) [40] 4 org/apache/jetspeed/container/window/impl/PortletWindowAccessorImpl 0x5a459e98
>  1,308,968,864 (81%) [48] 4 java/util/Collections$SynchronizedMap 0x5a459ee8
>   1,308,968,752 (81%) [64] 3 java/util/HashMap 0x5a459eb8
>    1,308,968,688 (81%) [81,320] 20,326 array of java/util/HashMap$Entry 0xaf52a080
> The above problem is addressed in JS2-800, where we can limit the number of PortletWindows in memory
> Combined with too many portlet windows in memory, the portlet content render buffers are held on to, and never released.
> This bug fix aids the garbage collection algorithm by "releasing" the buffers upon render completion
> Note I have seen some very large buffers held on to and never released.
> By setting the streams to null, we can try to aid the garbage collection into freeing these buffers

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