[
https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019442#comment-13019442
]
Jeanne Waldman commented on TRINIDAD-1985:
------------------------------------------
The LRUCache.patch should be for the related issue TRINIDAD-2026 memory leak in
skinstyleprovider. This occurs if one application uses a bunch of different
skins.
> High live memory usage from SkinStyleProvider
> ---------------------------------------------
>
> Key: TRINIDAD-1985
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Archetype
> Affects Versions: 1.2.12-core
> Reporter: Stevan Malesevic
> Assignee: Jeanne Waldman
> Attachments: LRUCache.patch
>
>
> We were checking a live memory usage in one app and noticed that some 83MB of
> heap is pinned under SkinStyleProvider. This is under 14 instances of
> FileSystemStyleCache$Entry each with about 6MB of memory
> Heap shows these keys for styles
> Locale Version
> en Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
> ko Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11)
> Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11)
> Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
> ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10
> (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10
> (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
> ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3)
> Gecko/20090824 Firefox/3.5.3
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3)
> Gecko/20090824 Firefox/3.5.3
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18)
> Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
> ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18)
> Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9)
> Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
> ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9)
> Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
> en Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET
> CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
> Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15)
> Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10)
> Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
> ko Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727;
> .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
> en Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727;
> .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12)
> Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16)
> Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
> ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16)
> Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
> en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
> Gecko/20101203 Firefox/3.6.13
> Now beside the amount of memory pinned by single FileSystemStyleCache$Entry
> the issue is that we apparently create too many different versions and there
> is no restriction to the size of cache leaving open door for memory leak
> Two questions
> 1. Do we really have different styles for FF on 3.5 or 3.6 or so? If not why
> do we key by it?
> 2. Given different browsers and locales having cache as plain concurrent hash
> map is actually a source of leak as over time it can accumulate more and
> more. Do we have any restriction there? Should the entries by LRU or have
> exparation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
