Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 12500 invoked from network); 5 Jan 2011 02:05:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jan 2011 02:05:07 -0000 Received: (qmail 41395 invoked by uid 500); 5 Jan 2011 02:05:07 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 41326 invoked by uid 500); 5 Jan 2011 02:05:07 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 41319 invoked by uid 99); 5 Jan 2011 02:05:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 02:05:07 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 02:05:06 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id p0524jX0016548 for ; Wed, 5 Jan 2011 02:04:45 GMT Message-ID: <18555276.150731294193085736.JavaMail.jira@thor> Date: Tue, 4 Jan 2011 21:04:45 -0500 (EST) From: "Jeanne Waldman (JIRA)" To: dev@myfaces.apache.org Subject: [jira] Issue Comment Edited: (TRINIDAD-1985) High live memory usage from SkinStyleProvider In-Reply-To: <4410113.216641292859961788.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977569#action_12977569 ] Jeanne Waldman edited comment on TRINIDAD-1985 at 1/4/11 9:02 PM: ------------------------------------------------------------------ For me to answer #1, I would need to know what skin you were using, and then I would look at the CSS files for that skin to see if we have different css for FF on 3.5 and 3.6 (like @agent gecko blocks). I see in the adf faces skins, we do have different styles for gecko 1.9.2 and lower: /* Firefox versions earlier than 3.6 (Gecko 1.9.2.0) do no support multiple background images */ And we do have slightly different styles for ko in Trinidad's base-desktop.css We have two types of caches in FileSystemStyleCache. One is am exact match (browser, locale, etc) key, and another is the derivationKey, and that keys off of the styleSheetNodes, so even if you are using different browsers or locales, if they have the same styleSheetNodes, then you will get the same cached value. What skin were you using? If we go with a most recently used limit, what do you think a reasonable limit would be? was (Author: jeanne.waldman@oracle.com): For me to answer #1, I would need to know what skin you were using, and then I would look at the CSS files for that skin to see if we have different css for FF on 3.5 and 3.6 (like @agent gecko blocks). What skin were you using? We have two types of caches in FileSystemStyleCache. One is a derivationKey, and that keys off of the styleSheetNodes, so even if you are using different browsers or locales, if they have the same styleSheetNodes, then you will get the same cached value. > 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 > > 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. - You can reply to this email to add a comment to the issue online.