Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 70700 invoked from network); 25 Aug 2006 08:20:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Aug 2006 08:20:26 -0000 Received: (qmail 33588 invoked by uid 500); 25 Aug 2006 08:20:22 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 33529 invoked by uid 500); 25 Aug 2006 08:20:22 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 33517 invoked by uid 99); 25 Aug 2006 08:20:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Aug 2006 01:20:22 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [85.197.127.214] (HELO mail.c-ware.de) (85.197.127.214) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Aug 2006 01:20:19 -0700 Received: (qmail 14318 invoked from network); 25 Aug 2006 07:58:18 -0000 Received: from unknown (HELO TIESTO) (213.157.25.113) by 0 with SMTP; 25 Aug 2006 07:58:18 -0000 From: "Christofer Dutz" To: Subject: AW: Memory remains claimed after continuation expiration Date: Fri, 25 Aug 2006 10:20:04 +0200 Message-ID: <000001c6c81f$44986fe0$0a42a8c0@univativ.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C830.08213FE0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000801c6c80d$56011780$6501a8c0@RBE4> Thread-Index: AcbICmGj+C4YzCJtR4yxyhai6ytPUAAFAf8w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_NextPart_000_0001_01C6C830.08213FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Rob, There is a monitor utility shipped with almost every VM. This can show you the exact memory-usage. On one of the tabs there is a button to manually trigger a big garbage-collection. I would guess that you are having the same problems we were having some months ago. If this is the case, the Cocoon is freeing the memory correctly. Unfortunately the algorithm detecting free memory portions doesn't recognize all free memory-areas and herby dos not free them. You will have to manually reconfigure the default GC settings of the VM. I have no experience of which flags result in the memory-leaks from disappearing, since I simply switched to another VM configured with better default GC setting ;) . yeeeah . have to admit, that I sometimes am really lazy ;) Hope I could help, Chris _____ Von: Rob Berens [mailto:rberens@osirion.nl] Gesendet: Freitag, 25. August 2006 08:12 An: users@cocoon.apache.org Betreff: Memory remains claimed after continuation expiration THIS MESSAGE WAS PREVIOUSLY POSTED TO THE DEVELOPERS LISTED ON 2006-08-24 I'm using cocoon 2.1.8 and noticed that in some cases memory remains claimed even after continuations have expired. Essentially the case is as follows: For test purposes I switched to a very low time-to-live for continuations: 30 seconds with an expiration check by the continuations manager every 30 seconds with an offset of 30 seconds. Session time out is 1 hour. So sessions live substantially longer than continuations. My webapp uses sessions. Consider the following js: function myPage() { var big = new VeryBigObject(); cocoon.sendPage("bigobjectPage.html", {big: big)}; } When calling this page many times one sees that memory is claimed for the big object and that it is released properly. I observed this by using the -verbose:gc flag on the VM. Now change to this (sendPageAndWait i.s.o. sendPage): function myPage() { var big = new VeryBigObject(); cocoon.sendPageAndWait("bigobjectPage.html", {big: big)}; // handle user response } Call this page once again and then have the user click away i.e. the sendPageAndWait does not return. Then after a while the contination expires and is neatly removed, but the memory for the big object appears to be claimed. Executing this function several times in the end leads to an out of memory error, even when previous continuations have expired. Am I doing something wrong or is this a bug? Later I also tried what happened when the user actually performs an action that makes the sendPageAndWait return. It appears that the memory remains claimed as well. Rob Berens Osirion B.V. ------=_NextPart_000_0001_01C6C830.08213FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Rob,

 =

There is a = monitor utility shipped with almost every VM. This can show you the exact = memory-usage. On one of the tabs there is a button to manually trigger a big garbage-collection. I would guess that you are having the same problems = we were having some months ago. If this is the case, the Cocoon is freeing the = memory correctly. Unfortunately the algorithm detecting free memory portions doesn’t recognize all free memory-areas and herby dos not free = them. You will have to manually reconfigure the default GC settings of the VM. I = have no experience of which flags result in the memory-leaks from disappearing, = since I simply switched to another VM configured with better default GC setting = ;) … yeeeah … have to admit, that I sometimes am really lazy = ;)

 =

Hope I could = help,

   = Chris

 =

Von: Rob Berens [mailto:rberens@osirion.nl]
Gesendet: Freitag, = 25. August 2006 08:12
An: = users@cocoon.apache.org
Betreff: Memory remains = claimed after continuation expiration

 

THIS MESSAGE WAS PREVIOUSLY POSTED TO THE DEVELOPERS = LISTED ON 2006-08-24

 

I'm using cocoon 2.1.8 and noticed that in some cases = memory remains claimed even after continuations have = expired.

 

Essentially the case is as = follows:

 

For test purposes I switched to a very low = time-to-live for continuations: 30 seconds with an expiration check by the continuations = manager every 30 seconds with an offset of 30 = seconds.

Session time out is 1 = hour.

So sessions live substantially longer than = continuations.

My webapp uses sessions.

 

Consider the following = js:

 

function myPage() {

    var big =3D new = VeryBigObject();

    cocoon.sendPage("bigobjectPage.html", {big: = big)};

}

 

When calling this page many times one sees that = memory is claimed for the big object and that it is released properly. I observed = this by using the -verbose:gc flag on the VM.

 

Now change to this (sendPageAndWait i.s.o. = sendPage):

 

function myPage() {

    var big =3D new = VeryBigObject();

    cocoon.sendPageAndWait("bigobjectPage.html", {big: = big)};

    // handle user = response

}

 

Call this page once again and then have the user = click away i.e. the sendPageAndWait does not return.

Then after a while the contination expires = and is neatly removed, but the memory for the big object appears to be = claimed.

Executing this function several times in the end = leads to an out of memory error, even when previous continuations have = expired.

 

Am I doing something wrong or is this a = bug?

 

Later I also tried what happened when the user = actually performs an action that makes the sendPageAndWait return. It = appears that the memory remains claimed as well. 

 

Rob Berens

Osirion B.V.

------=_NextPart_000_0001_01C6C830.08213FE0--