You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Bill Nagy <na...@watson.ibm.com> on 2006/10/10 04:51:58 UTC
[Axis2] Proposal to add return type to Handler.invoke(...)
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.
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. :
/**
* 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.)
Comments?
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Davanum Srinivas <da...@gmail.com>.
Let's get it over with. +1 to both HEAD and 1.1 branch.
-- dims
On 10/18/06, Sanjiva Weerawarana <sa...@opensource.lk> 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: 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
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-10-18 at 22:24 -0700, Bill Nagy wrote:
> 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.
I'm fine with a multivalue return; it seems cleaner than having a
property and a return option. I'd prefer an int (consts) return type but
I can live with an inner class and your returning stuff from that (as
originally proposed).
Please go ahead with whichever option you pick so that we can get this
into the 1.1 builds sooner than later.
Thanks!
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Bill Nagy <na...@watson.ibm.com>.
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: 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
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: 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
>
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Bill Nagy <na...@watson.ibm.com>.
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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Invoke a EJB in a axis2 service
Posted by robert lazarski <ro...@gmail.com>.
I'll take a look at it in the next day or two.
Robert
On 10/12/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Wed, 2006-10-11 at 15:58 +0200, Jesús Daniel Blázquez Carazo wrote:
> > In the previous axis version it was easy because there was the
> > org.apache.axis.providers.java.EJBprovider class. This class communicates
> > read the server-config.wsdd file to get the parameters to communicate with
> > the EJB. But this new version has a different architecture and this is not
> > possible. I need an alternative to do the same.
> >
> > I am retrieving in the code of the EJBProvider class to try do this.
>
> What we need to do is to convert the EJBProvider into a message
> receiver .. then we can have the same functionality as before.
>
> Robert, any chance you can crack it? :)
>
> 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
Re: Invoke a EJB in a axis2 service
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-10-11 at 15:58 +0200, Jesús Daniel Blázquez Carazo wrote:
> In the previous axis version it was easy because there was the
> org.apache.axis.providers.java.EJBprovider class. This class communicates
> read the server-config.wsdd file to get the parameters to communicate with
> the EJB. But this new version has a different architecture and this is not
> possible. I need an alternative to do the same.
>
> I am retrieving in the code of the EJBProvider class to try do this.
What we need to do is to convert the EJBProvider into a message
receiver .. then we can have the same functionality as before.
Robert, any chance you can crack it? :)
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Invoke a EJB in a axis2 service
Posted by robert lazarski <ro...@gmail.com>.
My recommendation is to file a jira asking for an axis2 port of
org.apache.axis.providers.java.EJBprovider . I might be able to take a
look at doing it if its straight forward.
Robert
On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
> Hi,
>
> My EJB must be a web service deployed in axis2 but I want to know how to use
> the EJB as a web service in axis2.
>
> In the previous axis version it was easy because there was the
> org.apache.axis.providers.java.EJBprovider class. This class communicates
> read the server-config.wsdd file to get the parameters to communicate with
> the EJB. But this new version has a different architecture and this is not
> possible. I need an alternative to do the same.
>
> I am retrieving in the code of the EJBProvider class to try do this.
>
> Thanks.
>
> ----- Original Message -----
> From: "robert lazarski" <ro...@gmail.com>
> To: <ax...@ws.apache.org>
> Sent: Wednesday, October 11, 2006 2:22 PM
> Subject: Re: Invoke a EJB in a axis2 service
>
>
> > Is your web service a client to an ejb or is the web service an actual
> > ejb, ie, 'implements SessionBean' etc ?
> >
> > Robert
> >
> > On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
> >> Hello.
> >>
> >> I am migrating the version of my deployed service from axis to axis2. My
> >> =
> >> problem is the following:
> >>
> >> - I need to execute a method of an EJB but i do not know exactly how to
> >> =
> >> do this.=20
> >> My first aproach is to type a new class with the same methods than the =
> >> EJB and call the EJB method from this. This class is included in the =
> >> final aar file.
> >> Here i need to use the interface classes of the EJB but I can not
> >>
> >> Any idea ?
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> > ejb, ie, 'implements SessionBean' etc ?
> >
> > Robert
> >
> > On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
> >> Hello.
> >>
> >> I am migrating the version of my deployed service from axis to axis2. My
> >> =
> >> problem is the following:
> >>
> >> - I need to execute a method of an EJB but i do not know exactly how to
> >> =
> >> do this.=20
> >> My first aproach is to type a new class with the same methods than the =
> >> EJB and call the EJB method from this. This class is included in the =
> >> final aar file.
> >> Here i need to use the interface classes of the EJB but I can not
> >>
> >> Any idea ?
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: Invoke a EJB in a axis2 service
Posted by Jesús Daniel Blázquez Carazo <jd...@gfi-info.com>.
Hi,
My EJB must be a web service deployed in axis2 but I want to know how to use
the EJB as a web service in axis2.
In the previous axis version it was easy because there was the
org.apache.axis.providers.java.EJBprovider class. This class communicates
read the server-config.wsdd file to get the parameters to communicate with
the EJB. But this new version has a different architecture and this is not
possible. I need an alternative to do the same.
I am retrieving in the code of the EJBProvider class to try do this.
Thanks.
----- Original Message -----
From: "robert lazarski" <ro...@gmail.com>
To: <ax...@ws.apache.org>
Sent: Wednesday, October 11, 2006 2:22 PM
Subject: Re: Invoke a EJB in a axis2 service
> Is your web service a client to an ejb or is the web service an actual
> ejb, ie, 'implements SessionBean' etc ?
>
> Robert
>
> On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
>> Hello.
>>
>> I am migrating the version of my deployed service from axis to axis2. My
>> =
>> problem is the following:
>>
>> - I need to execute a method of an EJB but i do not know exactly how to
>> =
>> do this.=20
>> My first aproach is to type a new class with the same methods than the =
>> EJB and call the EJB method from this. This class is included in the =
>> final aar file.
>> Here i need to use the interface classes of the EJB but I can not
>>
>> Any idea ?
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> ejb, ie, 'implements SessionBean' etc ?
>
> Robert
>
> On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
>> Hello.
>>
>> I am migrating the version of my deployed service from axis to axis2. My
>> =
>> problem is the following:
>>
>> - I need to execute a method of an EJB but i do not know exactly how to
>> =
>> do this.=20
>> My first aproach is to type a new class with the same methods than the =
>> EJB and call the EJB method from this. This class is included in the =
>> final aar file.
>> Here i need to use the interface classes of the EJB but I can not
>>
>> Any idea ?
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Invoke a EJB in a axis2 service
Posted by robert lazarski <ro...@gmail.com>.
Is your web service a client to an ejb or is the web service an actual
ejb, ie, 'implements SessionBean' etc ?
Robert
On 10/11/06, Jesús Daniel Blázquez Carazo <jd...@gfi-info.com> wrote:
> Hello.
>
> I am migrating the version of my deployed service from axis to axis2. My =
> problem is the following:
>
> - I need to execute a method of an EJB but i do not know exactly how to =
> do this.=20
> My first aproach is to type a new class with the same methods than the =
> EJB and call the EJB method from this. This class is included in the =
> final aar file.
> Here i need to use the interface classes of the EJB but I can not
>
> Any idea ?
>
>
> ---------------------------------------------------------------------
> 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
Invoke a EJB in a axis2 service
Posted by Jesús Daniel Blázquez Carazo <jd...@gfi-info.com>.
Hello.
I am migrating the version of my deployed service from axis to axis2. My =
problem is the following:
- I need to execute a method of an EJB but i do not know exactly how to =
do this.=20
My first aproach is to type a new class with the same methods than the =
EJB and call the EJB method from this. This class is included in the =
final aar file.
Here i need to use the interface classes of the EJB but I can not
Any idea ?
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Bill Nagy <na...@watson.ibm.com>.
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
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
On 10/10/06, Srinath Perera <he...@gmail.com> wrote:
> +1
>
> On 10/9/06, Bill Nagy <na...@watson.ibm.com> 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.
> >
> > 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. :
> >
> > /**
> > * 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.)
> >
> > Comments?
> >
> > -Bill
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> ============================
> Srinath Perera:
> Indiana University, Bloomington
> http://www.cs.indiana.edu/~hperera/
> http://www.bloglines.com/blog/hemapani
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Posted by Srinath Perera <he...@gmail.com>.
+1
On 10/9/06, Bill Nagy <na...@watson.ibm.com> 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.
>
> 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. :
>
> /**
> * 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.)
>
> Comments?
>
> -Bill
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
============================
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org