You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Rob Berens <rb...@osirion.nl> on 2006/08/25 08:11:37 UTC
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.
RE: problem with setting initial value of fieldwidget used in repeaterwidget
Posted by "Robby Pelssers, AGP" <ro...@agp.nl>.
I checked JIRA and this problem was already closed. So this answers my
question ....It was a bug.
Cheers,
Robby
-----Oorspronkelijk bericht-----
Van: Robby Pelssers, AGP [mailto:robby.pelssers@agp.nl]
Verzonden: maandag 28 augustus 2006 11:20
Aan: users@cocoon.apache.org
Onderwerp: problem with setting initial value of fieldwidget used in
repeaterwidget
Hi,
I get a nullpointerexception when adding the line
<fd:initial-value>0</fd:initial:value> for the field-widget 'monday'.
<fd:form>
<fd:widgets>
<fd:repeater id="projects">
<fd:widgets>
<fd:field id="contract">
<fd:label>Contracts</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="monday">
<fd:label>Maandag</fd:label>
<fd:datatype base="integer"/>
<fd:initial-value>0</fd:initial-value>
<fd:on-value-changed>
<javascript>
event.source.form.getAttribute("controller").handleHoursOfDa
yValueChanged(event, viewData);
</javascript>
</fd:on-value-changed>
</fd:field>
<fd:field id="tuesday">
<fd:label>Dinsdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="wednesday">
<fd:label>Woensdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="thursday">
<fd:label>Donderdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="friday">
<fd:label>Vrijdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:output id="rowtotal">
<fd:label>Totaal</fd:label>
<fd:datatype base="integer"/>
</fd:output>
</fd:widgets>
</fd:repeater>
</fd:widgets>
</fd:form>
Anybody experienced the same problem?
Kind regards,
Robby Pelssers
problem with setting initial value of fieldwidget used in repeaterwidget
Posted by "Robby Pelssers, AGP" <ro...@agp.nl>.
Hi,
I get a nullpointerexception when adding the line
<fd:initial-value>0</fd:initial:value> for the field-widget 'monday'.
<fd:form>
<fd:widgets>
<fd:repeater id="projects">
<fd:widgets>
<fd:field id="contract">
<fd:label>Contracts</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="monday">
<fd:label>Maandag</fd:label>
<fd:datatype base="integer"/>
<fd:initial-value>0</fd:initial-value>
<fd:on-value-changed>
<javascript>
event.source.form.getAttribute("controller").handleHoursOfDayV
alueChanged(event, viewData);
</javascript>
</fd:on-value-changed>
</fd:field>
<fd:field id="tuesday">
<fd:label>Dinsdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="wednesday">
<fd:label>Woensdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="thursday">
<fd:label>Donderdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="friday">
<fd:label>Vrijdag</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:output id="rowtotal">
<fd:label>Totaal</fd:label>
<fd:datatype base="integer"/>
</fd:output>
</fd:widgets>
</fd:repeater>
</fd:widgets>
</fd:form>
Anybody experienced the same problem?
Kind regards,
Robby Pelssers
AW: Memory remains claimed after continuation expiration
Posted by Christofer Dutz <du...@c-ware.de>.
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.