From olio-user-return-336-apmail-incubator-olio-user-archive=incubator.apache.org@incubator.apache.org Fri Mar 26 20:20:12 2010 Return-Path: Delivered-To: apmail-incubator-olio-user-archive@minotaur.apache.org Received: (qmail 71901 invoked from network); 26 Mar 2010 20:20:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 Mar 2010 20:20:12 -0000 Received: (qmail 74758 invoked by uid 500); 26 Mar 2010 20:20:12 -0000 Delivered-To: apmail-incubator-olio-user-archive@incubator.apache.org Received: (qmail 74718 invoked by uid 500); 26 Mar 2010 20:20:12 -0000 Mailing-List: contact olio-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: olio-user@incubator.apache.org Delivered-To: mailing list olio-user@incubator.apache.org Received: (qmail 74710 invoked by uid 99); 26 Mar 2010 20:20:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 20:20:12 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [65.115.85.69] (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 20:20:03 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id D7DA2E00C for ; Fri, 26 Mar 2010 13:19:41 -0700 (PDT) Received: from pa-excaht04.vmware.com (pa-excaht04.vmware.com [10.113.81.155]) by mailhost3.vmware.com (Postfix) with ESMTP id D07A6CD913 for ; Fri, 26 Mar 2010 13:19:41 -0700 (PDT) Received: from EXCH-MBX-4.vmware.com ([10.113.81.233]) by pa-excaht04.vmware.com ([10.113.81.155]) with mapi; Fri, 26 Mar 2010 13:19:41 -0700 From: Harold Rosenberg To: "olio-user@incubator.apache.org" Date: Fri, 26 Mar 2010 13:19:33 -0700 Subject: Memory leak in Olio/Java? Thread-Topic: Memory leak in Olio/Java? Thread-Index: AcrNIaWtM4eYZ7yhSvO97yVkTRSusQ== Message-ID: <89E2752CFA8EC044846EB8499819134102AD4A649C@EXCH-MBX-4.vmware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_89E2752CFA8EC044846EB8499819134102AD4A649CEXCHMBX4vmwar_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_89E2752CFA8EC044846EB8499819134102AD4A649CEXCHMBX4vmwar_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been doing some testing with the Java version of Olio (on Glassfish = v3), and have noticed that there appears to be a memory leak in the applica= tion. I never seem to run into an out-of-memory exception (although I may = not have run long enough), but if I watch the heap with visualgc, I can see= that the tenured generation slowly fills up, and when a full gc occurs ver= y little space is freed. If I run long enough, the tenured generation gets= entirely full and the application spends all of its time in gc. At first I thought that this was due to running with the MapCache. However= the same thing happens even if I disable caching. From looking at a heap = dump, it appears that it is possible that eclipselink may be holding on to = references to every object that it creates, although I'm not sure that I un= derstand what is happening well enough to be sure. Has anyone else seen this? I would like to be able to run for a long time,= and this effectively prevents that from working. Any ideas on how to fix = this? Thanks, Hal Rosenberg --_000_89E2752CFA8EC044846EB8499819134102AD4A649CEXCHMBX4vmwar_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been doing some testing with the Java version o= f Olio (on Glassfish v3), and have noticed that there appears to be a memory leak = in the application.  I never seem to run into an out-of-memory exception (although I may not have run long enough), but if I watch the heap with visualgc, I can see that the tenured generation slowly fills up, and when a full gc occurs very little space is freed.  If I run long enough, the tenured generation gets entirely full and the application spends all of its time in gc.

 

At first I thought that this was due to running with t= he MapCache.  However the same thing happens even if I disable caching.&n= bsp; From looking at a heap dump, it appears that it is possible that eclipselin= k may be holding on to references to every object that it creates, although IR= 17;m not sure that I understand what is happening well enough to be sure.  =

 

Has anyone else seen this?  I would like to be ab= le to run for a long time, and this effectively prevents that from working. = Any ideas on how to fix this?

 

Thanks,

 

Hal Rosenberg

 

--_000_89E2752CFA8EC044846EB8499819134102AD4A649CEXCHMBX4vmwar_--