axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <n...@watson.ibm.com>
Subject Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Date Wed, 11 Oct 2006 01:20:08 GMT
Hi Sanjiva,

The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.

I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)

Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.

I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.

-Bill

On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote: 
> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message