Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of joerg.heinicke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <47EF44BD.20907@gmx.de>
Date: Sun, 30 Mar 2008 03:43:57 -0400
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
 rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Javaflow - major memory issue
References: <966697.91329.qm@web57908.mail.re3.yahoo.com>
 <47EB230C.9090805@gmx.de> <927C343A-D85A-49F3-9D23-684F7B206E86@apache.org>
 <47EB9079.6010702@gmx.de> <6D111B22-8FF9-4B48-A1D5-D984CBC55BD8@apache.org>
 <loom.20080327T140929-115@post.gmane.org>
 <C82D2DC2-DC19-4E42-9841-44BC25AB5A51@apache.org> <47EC6631.6030302@gmx.de>
 <AA31397A-9F95-4434-AD80-0DCBA028A009@apache.org>
In-Reply-To: <AA31397A-9F95-4434-AD80-0DCBA028A009@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 28.03.2008 04:55, Torsten Curdt wrote:

>> The output I showed pointed to 
>> org.apache.cocoon.components.flow.java.Continuation which only seems 
>> to exist in Cocoon 2.1. Nothing unsets the context there.
> 
> Hah - well spotted!
> 
>> Having a look into the code continuations are only handled by 
>> JavaInterpreter. There are two methods callFunction(..) and 
>> handleContinuation(..) calling Continuation.registerThread() and 
>> deregisterThread() in a finally block. From a brief look I have no 
>> idea if I can just unset the ContinuationContext there as well. You 
>> might know more about it.
> 
> We should add a try/finally block in Continuation.suspend() that clears 
> the context after a suspend. That should fix it.

Unfortunately, it is not possible to unset the ContinuationContext 
completely. It's needed in JavaInterpreter.handleContinuation(..) when a 
child continuation is created:

   Continuation parentContinuation =
       (Continuation) parentwk.getContinuation();
   ContinuationContext parentContext =
       (ContinuationContext) parentContinuation.getContext();
   ContinuationContext context = new ContinuationContext();
   context.setObject(parentContext.getObject());
   context.setMethod(parentContext.getMethod());

Without completely rewriting it the only thing I did was to remove the 
data in the ContinuationContext that is not necessary. I do this by an 
extra call to ContinuationContext.onSuspend() in AbstractContinuable 
since Continuation is not aware of the implementation of its context 
(it's just an Object).

Please review my changes [1] because I'm not really sure about them. 
They work for the normal case, but what happens in an error case? I 
can't see what's really going on except that the method is left on 
Continuation.suspend() ... It was very interesting to debug it when 
AbstractContinuable.sendPageAndWait(..) was actually hit twice.

I guess this handling is different in 2.2. There a clean 
ContinuationContext is created on both callFunction(..) and 
handleContinuation(..).

Joerg

[1] http://svn.apache.org/viewvc?rev=642694&view=rev