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"?
Well, of course you pay a runtime penalty for another method
invocation ....unless the hotspots is able to optimize that away. Not
sure.
But it's less about optimization - more about keeping the
synchronization more visible. But as long as the access to the hashmap
is simple like it is right now I would not argue about it :)
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.
Just to have it as post condition. You never know.
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.
+1
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.
Yeah, it's interesting isn't it? :)
cheers
--
Torsten
