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.
Joerg
