On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
> There is currently a race condition between code that pauses the message
> flow within a handler and resumes it on another thread (e.g. Sandesha)
> and the message flow processing chain (Phase.invoke(...),
> AxisEngine.invoke(...), etc.)
> (http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
> because the control of processing is keyed off of MessageContext.paused
> and not through some other mechanism (return code, semaphore, etc.). If
> a handler pauses a message and returns, handing the message off to
> another thread for execution, there is the possibility that the new
> execution thread will resume processing of the message, unsetting
> MessageContext.paused, before control returns to one of the invoke
> methods. If this happens, the logic in the invoke method, which looks
> at the MessageContext.paused flag, will believe that it should continue
> execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
> Since the problem revolves around flow control logic, I suggest that we
> use the return code from the method invocation to deal with it. I would
> like to add a return code to the Handler.invoke(...) which would
> identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
> /**
> * This type encapsulates an enumeration of possible message processing
> * instruction values that may be returned by a handler/phase within the
> * runtime.
> */
> public class InvocationProcessingInstruction
> {
> public static InvocationProcessingInstruction CONTINUE_PROCESSING =
> new InvocationProcessingInstruction(0);
> public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
> InvocationProcessingInstruction(1);
> public static InvocationProcessingInstruction ABORT_PROCESSING = new
> InvocationProcessingInstruction(2);
>
> private int instructionID;
>
> private InvocationProcessingInstruction(int instructionID)
> {
> this.instructionID = instructionID;
> }
>
> public boolean equals(InvocationProcessingInstruction instruction)
> {
> return this.instructionID == instruction.instructionID;
> }
>
> public int hashCode()
> {
> return instructionID;
> }
> }
>
> Most handlers will return
> InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
> return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
> a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
