Hi Peter,
> 2. The exception was thrown during bytecode rewrite of my
> Sequence.execute() method. This snippet of ResumableMethodAdapter
> throws the exception:
> ...
> else if (mConfig.getCallMethodName().equals(name) && ...
> {
> // store the call target
> debugMessage("CONT: call : storing call target");
> mMethodVisitor.visitVarInsn(ASTORE, mCallTargetIndex);
>
> // pop the ALOAD opcode off the stack
> debugMessage("CONT: call : undoing method call");
> mMethodVisitor.visitInsn(POP);
>
> TypesContext context = mTypes.nextPauseContext();
> Stack<String> stack = context.getStackClone();
> stack.pop(); <-------
> debugMessage("CONT: call : saving operand stack");
> saveOperandStack(stack);
> ...
>
> I interpreted this as me using call() in a location where it is not
> allowed. (and maybe it is not allowed)
>
> Allthough I have not enough understanding of the code I tried
> modifying it like this:
> if(!stack.empty())
> stack.pop();
>
> This made my call-answer sample run!
> Could you comment on what is happening?
I made a fix related to this last week, can you please try with the
last snapshot of RIFE/Continuations?
http://rifers.org/downloads/rife/snapshots/rife-1.6.2-snapshot-20071110/
If you still get the exception, would it be possible to provide an
archive of your project (possibly in private email), so that I can
reproduce the exception here?
> 3. About the rife-workflow project: I was surprised to see that it
> uses multiple threads. What is the rationale for this? My goal is to
> perform a sequence of blocking calls, all on the same thread to avoid
> synchronization issues due to preemtive thread switching. I guess the
> threads in rife-workflow don't have a lot of interaction because they
> just run until a blocking action is performed and then they exit.
> Still I would think using just one thread is also possible.
I suppose this depends on what your use-case is, the purpose of the
multi-threading is that in a workflow system you can have several long
running tasks that are active at once, without necessarily being
dependent on other tasks. I merely pointed you to the project so that
you could see an example of call/answer outside of a web app context.
However, it would be cool to figure out a way to add the single-
threaded behavior to RIFE/Workflow since if you need this, others
might too. Maybe the task class can contain a String getThreadName()
method with a default implementation of 'null'. When that's not null,
tasks with the same thread name are all executed in the same single
thread.
What do you think? Care to have a shot at adding this to RIFE/Workflow?
Take care,
Geert
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"rife-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---
