cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Javaflow - major memory issue
Date Sun, 30 Mar 2008 15:29:43 GMT
On 30.03.2008 07:35, Torsten Curdt wrote:

> There is no need to really obtain that value from the parent. If 
> handleContinuation would have also the function parameter it could use 
> the same initialization as in callFuntion.

Yes, if the function name would have been available ... This was beyond 
what I wanted to do. But since you confirmed it now I risked this change.

> Actually a way of fixing this 
> would be to add two Strings to the Continuation class. One holding the 
> classname, the other holding the method name. And then do
> context.setObject(userScopes.get(parentContinuation.getScopeName()));
> context.setMethod(methods.get(parentContinuation.getFunctionName()));

The scopes are by Class. Therefore I only stored the function name and 
retrieved the method.

> in handleContinuation. Then the cleaning of the context should be fine.

Yes, it's better now.

>> 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.
> Not a fan of the Collections.synchronizedMap(new HashMap()) change - but 

Just curious, any reason for this? Is it not "as optimized"?

> other than that they look OK on the first glance :)
>> 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.
> :) ...what error case do you mean?

Not sure, originally you proposed to put it into a try finally block.

>> I guess this handling is different in 2.2. There a clean 
>> ContinuationContext is created on both callFunction(..) and 
>> handleContinuation(..).
> Indeed ...that would be another fix ...porting it from 2.2 :)

That's really beyond what I want to do ;-) Let's leave the good stuff 
for 2.2.

> Thanks for looking into that.

It was really interesting to see how a Java method is cut into two 
pieces. Suddenly the debugger stops stepping, but just leaves the 
methods. And on the next call it just jumps to the appropriate places in 
the code. Once you get used to it it's easy to debug. I have never tried 
it before but now I like it better than flowscript.


View raw message