Sold, but I was OK on waiting until after 1.1 as the handler unwind stuff changed the Handler interface anyways. We still need either the multi-value return type or another property in the MessageContext to indicate that message processing should abort vs pause (so that the handler unwind can happen vs not.) [We may simply be able to replace the MessageContext.ispaused property with a MessageContext.isaborted property, as there shouldn't be a race condition with that one, and then implicitly intrepret a false returned with isAborted==false as the message is just paused. This is a little less clear in my opinion, but would do the job.]
If you'd rather have the property, I'm fine with that -- I just want to make the decision now and not have to change the interface again later. -Bill On Thu, 2006-10-19 at 04:57 +0530, Sanjiva Weerawarana wrote: > OK how about this alternative- let's make this change on the HEAD and > the 1.1 branch now? That way we do it and finish it off. > > Sanjiva. > > On Wed, 2006-10-18 at 11:05 +0530, Sanjiva Weerawarana wrote: > > Sorry for the delay Bill. > > > > +1 to your solution. However I'd personally prefer if you change the > > return type to be boolean: true means paused and false means all is > > cool. > > > > I'm very wary of executing thing change right now because it'll break > > all downstream projects including Rahas/Rampart/Sandesha/Synapse etc. > > which have not cut 1.1 branches. We definitely want them to run on Axis2 > > 1.1 and so its necessary to not change them. Is there any way to wait > > until we get back onto one trunk? > > > > Or maybe the right answer is for those projects to branch too now. > > > > Thoughts? > > > > Sanjiva. > > > > On Tue, 2006-10-17 at 06:39 -0700, Bill Nagy wrote: > > > Do you still have an objection to this Sanjiva? > > > > > > -Bill > > > > > > On Tue, 2006-10-10 at 18:20 -0700, Bill Nagy wrote: > > > > 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: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
