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 pr...@apache.org on 2007/02/28 18:43:08 UTC
svn commit: r512869 -
/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Author: pradine
Date: Wed Feb 28 09:43:07 2007
New Revision: 512869
URL: http://svn.apache.org/viewvc?view=rev&rev=512869
Log:
Do something more useful than throw an exception.
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Modified: webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java?view=diff&rev=512869&r1=512868&r2=512869
==============================================================================
--- webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java (original)
+++ webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java Wed Feb 28 09:43:07 2007
@@ -137,16 +137,18 @@
log.debug(msgctx.getLogIDString()+" "+Messages.getMessage("checkingrelatesto",
relatesTo));
}
- if ((relatesTo != null) && !"".equals(relatesTo)) {
+ if (relatesTo != null && !"".equals(relatesTo)) {
OperationContext operationContext =
msgctx.getConfigurationContext()
.getOperationContext(relatesTo);
if (operationContext != null) {
if(operationContext.isComplete()){
- // If the dispatch happens because of the RelatesTo and the mep is complete
- // we should throw a more descriptive fault.
- throw new AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
+ if(LoggingControl.debugLoggingAllowed && log.isDebugEnabled()){
+ log.debug(msgctx.getLogIDString()+" Operation context is marked as complete. Calling cleanup on it.");
+ }
+ operationContext.cleanup();
+ return InvocationResponse.CONTINUE;
}
msgctx.setAxisOperation(operationContext.getAxisOperation());
msgctx.setOperationContext(operationContext);
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by David Illsley <da...@gmail.com>.
Oops, I misunderstood the change. I added the explicit check and fault
in the last couple of weeks because there was a timing window when
sandesha is engaged where the duplicate message is detected deep in
axis2 and the fault was confusing (unclear to any non-axis2-dev).
I guess this change is simply a cleaner way of achieving the same
thing - a clear fault when
a duplicate occurs... so I'm happy again.
David
On 01/03/07, Brian De Pradine <PR...@uk.ibm.com> wrote:
>
> Hello,
>
> Apologies for not making the intent clearer. We are not swallowing the
> message, but instead simply allowing it to continue on it's way through the
> flow. The idea is that we do not have enough information in the
> AddressingBasedDispatcher to determine that such messages are 'bad'. Instead
> we want to allow other layers such as WS-RM to see, and possibly handle,
> such duplicate messages.
>
> Cheers
>
> Brian DePradine
> Web Services Development
> IBM Hursley
> External +44 (0) 1962 816319 Internal 246319
>
> If you can't find the time to do it right the first time, where will you
> find the time to do it again?
>
>
> Sanjiva Weerawarana <sa...@opensource.lk> wrote on 01/03/2007 01:47:46:
>
>
> > +1 but I'm confused why we'd remove this exception .. if someone sends a
> > response message again we should be saying "nope been there done that
> > already" back to the sender. If you eat the exception and log it they
> have
> > no info. What is broken about the old code?
> >
> > Sanjiva.
> >
> > David Illsley wrote:
> > > Hi Brian,
> > > I think it's important that if this (message being swallowed) is
> > > happening, that we make it very obvous. What do you think about
> > > logging at a higher level than debug?
> > > David
> > >
> > > On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> > >> Author: pradine
> > >> Date: Wed Feb 28 09:43:07 2007
> > >> New Revision: 512869
> > >>
> > >> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> > >> Log:
> > >> Do something more useful than throw an exception.
> > >>
> > >> Modified:
> > >>
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >>
> > >>
> > >> Modified:
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >>
> > >> URL:
> > >> http://svn.apache.
> >
> org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java?view=diff&rev=512869&r1=512868&r2=512869
> > >>
> > >>
> >
> ==============================================================================
> > >>
> > >> ---
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >> (original)
> > >> +++
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >> Wed Feb 28 09:43:07 2007
> > >> @@ -137,16 +137,18 @@
> > >> log.debug(msgctx.getLogIDString()+"
> > >> "+Messages.getMessage("checkingrelatesto",
> > >> relatesTo));
> > >> }
> > >> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> > >> + if (relatesTo != null && !"".equals(relatesTo)) {
> > >> OperationContext operationContext =
> > >> msgctx.getConfigurationContext()
> > >>
> .getOperationContext(relatesTo);
> > >>
> > >> if (operationContext != null) {
> > >> if(operationContext.isComplete()){
> > >> - // If the dispatch happens because of the
> > >> RelatesTo and the mep is complete
> > >> - // we should throw a more descriptive fault.
> > >> - throw new
> > >>
> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> > >> +
> if(LoggingControl.debugLoggingAllowed &&
> > >> log.isDebugEnabled()){
> > >> + log.debug(msgctx.getLogIDString()+"
> > >> Operation context is marked as complete. Calling cleanup on it.");
> > >> + }
> > >> + operationContext.cleanup();
> > >> + return InvocationResponse.CONTINUE;
> > >> }
> > >>
> > >>
> msgctx.setAxisOperation(operationContext.getAxisOperation());
> > >> msgctx.setOperationContext(operationContext);
> > >>
> > >>
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
> axis-cvs-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-cvs-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
>
> ________________________________
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
(sorry, there was a mistake in the previous post)
On 3/5/07, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Hi Matt,
>
> Thanks for the clarification. Please see below.
>
> On 3/4/07, Matthew Lovett <MLOVETT@uk.ibm.com > wrote:
> >
> > "Chamikara Jayalath" < chamikaramj@gmail.com> wrote on 04/03/2007
> > 02:55:45:
> >
> > > Hi Brian, All,
> > >
> > > This is why we were acking this kind of messages in our global
> > handler.
> > >
> > > Matt, what was the reason for moving this logic to the
> > > SandeshaInHandler. The comment did not help much :-(
> > > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> > >
> > > Chamikara
> > >
> > >
> >
> > Hi Chamikara,
> >
> > I moved the logic because I was trying to sort out the duplicate
> > processing - the old code didn't work either. There were several issues:
> > 1) There was a timing window between the global in handler & the
> > sandesha
> > in handler. That meant that messages arriving close together would both
> > pass through the global in handler, so we had to re-do the duplicate
> > checking in the in handler too. Generally duplicate code is bad, right?
>
>
> What about having both the duplicate handling logic, and the
> message identification logic (I.e. marking this message as received) at
> the GIH.
> This way we do not need to redo the duplicate detection.
>
> 2) Some of the actions we took in the global in handler actually relied
> on
>
> > the service & operation being resolved, so they didn't actually work. I
> > think one case that failed was the wsrm 1.0 replay-the-response message
> > stuff, but some of the ack logic failed as well.
>
>
>
> Wasn't the GlobalInHandler placed in a place between service/operation
> dispatching and the
> instance dispatching. So it already had the service/operation information
> and that's what
> we were using. Not sure whether some change in Axis2 had broken this by
> the time you were
> checking.
>
> I hoped that putting all the code in one place, post dispatch, would help
> > - but obviously we have hit this issue too. I think that the right
> > solution might be to put some logic back into the global in handler - if
> > we filtered duplicates there, and stored new messages, then something
> > like
> > the inOrderInvoker could pick them up and drive them through the rest of
> > the engine. This sounds better to me, especially if we restructure so
> > that
> > we _know_ we have stored the message before we ack it. I think we might
> > have some timing windows there at the moment.
> >
> > However, that's a fair bit of rework - does it sound like the right
> > direction to follow?
>
>
>
> The rest of the logic I think should be in the SandeshaInHandler. For two
> reasons,
>
> 1. To maximize the performance - every message that come to the system
> will go through the GIH.
> 2. By the time the GIH is hit, the context information is not available.
> We may need that in some
> of our logic.
>
> Chamikara
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
(sorry, there was a mistake in the previous post)
On 3/5/07, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Hi Matt,
>
> Thanks for the clarification. Please see below.
>
> On 3/4/07, Matthew Lovett <MLOVETT@uk.ibm.com > wrote:
> >
> > "Chamikara Jayalath" < chamikaramj@gmail.com> wrote on 04/03/2007
> > 02:55:45:
> >
> > > Hi Brian, All,
> > >
> > > This is why we were acking this kind of messages in our global
> > handler.
> > >
> > > Matt, what was the reason for moving this logic to the
> > > SandeshaInHandler. The comment did not help much :-(
> > > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> > >
> > > Chamikara
> > >
> > >
> >
> > Hi Chamikara,
> >
> > I moved the logic because I was trying to sort out the duplicate
> > processing - the old code didn't work either. There were several issues:
> > 1) There was a timing window between the global in handler & the
> > sandesha
> > in handler. That meant that messages arriving close together would both
> > pass through the global in handler, so we had to re-do the duplicate
> > checking in the in handler too. Generally duplicate code is bad, right?
>
>
> What about having both the duplicate handling logic, and the
> message identification logic (I.e. marking this message as received) at
> the GIH.
> This way we do not need to redo the duplicate detection.
>
> 2) Some of the actions we took in the global in handler actually relied
> on
>
> > the service & operation being resolved, so they didn't actually work. I
> > think one case that failed was the wsrm 1.0 replay-the-response message
> > stuff, but some of the ack logic failed as well.
>
>
>
> Wasn't the GlobalInHandler placed in a place between service/operation
> dispatching and the
> instance dispatching. So it already had the service/operation information
> and that's what
> we were using. Not sure whether some change in Axis2 had broken this by
> the time you were
> checking.
>
> I hoped that putting all the code in one place, post dispatch, would help
> > - but obviously we have hit this issue too. I think that the right
> > solution might be to put some logic back into the global in handler - if
> > we filtered duplicates there, and stored new messages, then something
> > like
> > the inOrderInvoker could pick them up and drive them through the rest of
> > the engine. This sounds better to me, especially if we restructure so
> > that
> > we _know_ we have stored the message before we ack it. I think we might
> > have some timing windows there at the moment.
> >
> > However, that's a fair bit of rework - does it sound like the right
> > direction to follow?
>
>
>
> The rest of the logic I think should be in the SandeshaInHandler. For two
> reasons,
>
> 1. To maximize the performance - every message that come to the system
> will go through the GIH.
> 2. By the time the GIH is hit, the context information is not available.
> We may need that in some
> of our logic.
>
> Chamikara
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
(sorry, there was a mistake in the previous post)
On 3/5/07, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Hi Matt,
>
> Thanks for the clarification. Please see below.
>
> On 3/4/07, Matthew Lovett <MLOVETT@uk.ibm.com > wrote:
> >
> > "Chamikara Jayalath" < chamikaramj@gmail.com> wrote on 04/03/2007
> > 02:55:45:
> >
> > > Hi Brian, All,
> > >
> > > This is why we were acking this kind of messages in our global
> > handler.
> > >
> > > Matt, what was the reason for moving this logic to the
> > > SandeshaInHandler. The comment did not help much :-(
> > > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> > >
> > > Chamikara
> > >
> > >
> >
> > Hi Chamikara,
> >
> > I moved the logic because I was trying to sort out the duplicate
> > processing - the old code didn't work either. There were several issues:
> > 1) There was a timing window between the global in handler & the
> > sandesha
> > in handler. That meant that messages arriving close together would both
> > pass through the global in handler, so we had to re-do the duplicate
> > checking in the in handler too. Generally duplicate code is bad, right?
>
>
> What about having both the duplicate handling logic, and the
> message identification logic (I.e. marking this message as received) at
> the GIH.
> This way we do not need to redo the duplicate detection.
>
> 2) Some of the actions we took in the global in handler actually relied
> on
>
> > the service & operation being resolved, so they didn't actually work. I
> > think one case that failed was the wsrm 1.0 replay-the-response message
> > stuff, but some of the ack logic failed as well.
>
>
>
> Wasn't the GlobalInHandler placed in a place between service/operation
> dispatching and the
> instance dispatching. So it already had the service/operation information
> and that's what
> we were using. Not sure whether some change in Axis2 had broken this by
> the time you were
> checking.
>
> I hoped that putting all the code in one place, post dispatch, would help
> > - but obviously we have hit this issue too. I think that the right
> > solution might be to put some logic back into the global in handler - if
> > we filtered duplicates there, and stored new messages, then something
> > like
> > the inOrderInvoker could pick them up and drive them through the rest of
> > the engine. This sounds better to me, especially if we restructure so
> > that
> > we _know_ we have stored the message before we ack it. I think we might
> > have some timing windows there at the moment.
> >
> > However, that's a fair bit of rework - does it sound like the right
> > direction to follow?
>
>
>
> The rest of the logic I think should be in the SandeshaInHandler. For two
> reasons,
>
> 1. To maximize the performance - every message that come to the system
> will go through the GIH.
> 2. By the time the GIH is hit, the context information is not available.
> We may need that in some
> of our logic.
>
> Chamikara
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
Thanks for the clarification. Please see below.
On 3/4/07, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 04/03/2007 02:55:45:
>
> > Hi Brian, All,
> >
> > This is why we were acking this kind of messages in our global handler.
> >
> > Matt, what was the reason for moving this logic to the
> > SandeshaInHandler. The comment did not help much :-(
> > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> >
> > Chamikara
> >
> >
>
> Hi Chamikara,
>
> I moved the logic because I was trying to sort out the duplicate
> processing - the old code didn't work either. There were several issues:
> 1) There was a timing window between the global in handler & the sandesha
> in handler. That meant that messages arriving close together would both
> pass through the global in handler, so we had to re-do the duplicate
> checking in the in handler too. Generally duplicate code is bad, right?
What about having both the duplicate handling logic, and the
message identification logic (I.e. marking this message as received) at the
GIH.
This way we do not need to redo the duplicate detection.
2) Some of the actions we took in the global in handler actually relied on
> the service & operation being resolved, so they didn't actually work. I
> think one case that failed was the wsrm 1.0 replay-the-response message
> stuff, but some of the ack logic failed as well.
Wasn't the GlobalInHandler placed in a place between service/operation
dispatching and the
instance dispatching. So it already had the service/operation information
and that's what
we were using. Not sure whether some change in Axis2 had broken this by the
time you were
checking.
I hoped that putting all the code in one place, post dispatch, would help
> - but obviously we have hit this issue too. I think that the right
> solution might be to put some logic back into the global in handler - if
> we filtered duplicates there, and stored new messages, then something like
> the inOrderInvoker could pick them up and drive them through the rest of
> the engine. This sounds better to me, especially if we restructure so that
> we _know_ we have stored the message before we ack it. I think we might
> have some timing windows there at the moment.
>
> However, that's a fair bit of rework - does it sound like the right
> direction to follow?
The rest of the logic I think should be in the SandeshaInHandler. For two
reasons,
1. To maximize the performance - every message that come to the system will
go through the GIH.
2. By the time the GIH is hit, the context information is been resolved. We
may need that in some
of our logic.
Chamikara
Thanks
>
> Matt
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
Thanks for the clarification. Please see below.
On 3/4/07, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 04/03/2007 02:55:45:
>
> > Hi Brian, All,
> >
> > This is why we were acking this kind of messages in our global handler.
> >
> > Matt, what was the reason for moving this logic to the
> > SandeshaInHandler. The comment did not help much :-(
> > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> >
> > Chamikara
> >
> >
>
> Hi Chamikara,
>
> I moved the logic because I was trying to sort out the duplicate
> processing - the old code didn't work either. There were several issues:
> 1) There was a timing window between the global in handler & the sandesha
> in handler. That meant that messages arriving close together would both
> pass through the global in handler, so we had to re-do the duplicate
> checking in the in handler too. Generally duplicate code is bad, right?
What about having both the duplicate handling logic, and the
message identification logic (I.e. marking this message as received) at the
GIH.
This way we do not need to redo the duplicate detection.
2) Some of the actions we took in the global in handler actually relied on
> the service & operation being resolved, so they didn't actually work. I
> think one case that failed was the wsrm 1.0 replay-the-response message
> stuff, but some of the ack logic failed as well.
Wasn't the GlobalInHandler placed in a place between service/operation
dispatching and the
instance dispatching. So it already had the service/operation information
and that's what
we were using. Not sure whether some change in Axis2 had broken this by the
time you were
checking.
I hoped that putting all the code in one place, post dispatch, would help
> - but obviously we have hit this issue too. I think that the right
> solution might be to put some logic back into the global in handler - if
> we filtered duplicates there, and stored new messages, then something like
> the inOrderInvoker could pick them up and drive them through the rest of
> the engine. This sounds better to me, especially if we restructure so that
> we _know_ we have stored the message before we ack it. I think we might
> have some timing windows there at the moment.
>
> However, that's a fair bit of rework - does it sound like the right
> direction to follow?
The rest of the logic I think should be in the SandeshaInHandler. For two
reasons,
1. To maximize the performance - every message that come to the system will
go through the GIH.
2. By the time the GIH is hit, the context information is been resolved. We
may need that in some
of our logic.
Chamikara
Thanks
>
> Matt
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
Thanks for the clarification. Please see below.
On 3/4/07, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 04/03/2007 02:55:45:
>
> > Hi Brian, All,
> >
> > This is why we were acking this kind of messages in our global handler.
> >
> > Matt, what was the reason for moving this logic to the
> > SandeshaInHandler. The comment did not help much :-(
> > ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
> >
> > Chamikara
> >
> >
>
> Hi Chamikara,
>
> I moved the logic because I was trying to sort out the duplicate
> processing - the old code didn't work either. There were several issues:
> 1) There was a timing window between the global in handler & the sandesha
> in handler. That meant that messages arriving close together would both
> pass through the global in handler, so we had to re-do the duplicate
> checking in the in handler too. Generally duplicate code is bad, right?
What about having both the duplicate handling logic, and the
message identification logic (I.e. marking this message as received) at the
GIH.
This way we do not need to redo the duplicate detection.
2) Some of the actions we took in the global in handler actually relied on
> the service & operation being resolved, so they didn't actually work. I
> think one case that failed was the wsrm 1.0 replay-the-response message
> stuff, but some of the ack logic failed as well.
Wasn't the GlobalInHandler placed in a place between service/operation
dispatching and the
instance dispatching. So it already had the service/operation information
and that's what
we were using. Not sure whether some change in Axis2 had broken this by the
time you were
checking.
I hoped that putting all the code in one place, post dispatch, would help
> - but obviously we have hit this issue too. I think that the right
> solution might be to put some logic back into the global in handler - if
> we filtered duplicates there, and stored new messages, then something like
> the inOrderInvoker could pick them up and drive them through the rest of
> the engine. This sounds better to me, especially if we restructure so that
> we _know_ we have stored the message before we ack it. I think we might
> have some timing windows there at the moment.
>
> However, that's a fair bit of rework - does it sound like the right
> direction to follow?
The rest of the logic I think should be in the SandeshaInHandler. For two
reasons,
1. To maximize the performance - every message that come to the system will
go through the GIH.
2. By the time the GIH is hit, the context information is been resolved. We
may need that in some
of our logic.
Chamikara
Thanks
>
> Matt
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Matthew Lovett <ML...@uk.ibm.com>.
"Chamikara Jayalath" <ch...@gmail.com> wrote on 04/03/2007 02:55:45:
> Hi Brian, All,
>
> This is why we were acking this kind of messages in our global handler.
>
> Matt, what was the reason for moving this logic to the
> SandeshaInHandler. The comment did not help much :-(
> ( http://svn.apache.org/viewvc?view=rev&revision=504544 )
>
> Chamikara
>
>
Hi Chamikara,
I moved the logic because I was trying to sort out the duplicate
processing - the old code didn't work either. There were several issues:
1) There was a timing window between the global in handler & the sandesha
in handler. That meant that messages arriving close together would both
pass through the global in handler, so we had to re-do the duplicate
checking in the in handler too. Generally duplicate code is bad, right?
2) Some of the actions we took in the global in handler actually relied on
the service & operation being resolved, so they didn't actually work. I
think one case that failed was the wsrm 1.0 replay-the-response message
stuff, but some of the ack logic failed as well.
I hoped that putting all the code in one place, post dispatch, would help
- but obviously we have hit this issue too. I think that the right
solution might be to put some logic back into the global in handler - if
we filtered duplicates there, and stored new messages, then something like
the inOrderInvoker could pick them up and drive them through the rest of
the engine. This sounds better to me, especially if we restructure so that
we _know_ we have stored the message before we ack it. I think we might
have some timing windows there at the moment.
However, that's a fair bit of rework - does it sound like the right
direction to follow?
Thanks
Matt
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Brian, All,
This is why we were acking this kind of messages in our global handler.
Matt, what was the reason for moving this logic to the SandeshaInHandler.
The comment did not help much :-(
( http://svn.apache.org/viewvc?view=rev&revision=504544 )
Chamikara
On 3/3/07, Brian De Pradine <PR...@uk.ibm.com> wrote:
>
>
> Hi Sanjiva,
>
> I will try my best. :-)
>
> Here is a WS-RM scenario that currently doesn't work,
>
> Client Server
> ------ ------
> | 1. Response |
> | <----------------------------------------- |
> | 2. Ack |
> | ---------------------------->X |
> | 3. Duplicate |
> | <----------------------------------------- |
> | 4. Ack |
> | -----------------------------------------> |
> | |
> | |
>
> In this scenario the server sends a response message to the client. The
> client then tries to send an acknowledgement to the server, but the
> acknowledgement gets lost, for whatever reason. This means that the WS-RM
> layer, in the server, will eventually time-out and send the response message
> again. This time the client should send an acknowledgement to cover both the
> original and the duplicate response messages.
>
> This scenario is broken because the duplicate response never makes it to
> the WS-RM layer on the client side, because the AddressingBasedDispatcher
> recognises it as a duplicate and throws an exception instead. This means
> that the WS-RM layer never gets driven to send the second acknowledgement.
> The result is that the server will simply keep sending duplicate responses
> forever (almost)!
>
> In order to get this scenario to work the AddressingBasedDispatcher will
> need to dispatch any duplicate messages as normal, instead of deciding that
> they are 'bad' and throwing an exception. This will allow WS-RM to be easily
> added into the picture at any time. This also means that if there is no
> WS-RM engaged then a service will potentially be driven more than once if
> there are duplicate messages (created by some other means). This shouldn't
> be a problem, however, because web services are meant to be stateless
> entities anyway :-) If you do happen to have a web service that is not
> stateless then you will need to engage WS-RM to ensure that it is not driven
> by duplicates.
>
> I hope this helps.
>
> Cheers
>
> Brian DePradine
> Web Services Development
> IBM Hursley
> External +44 (0) 1962 816319 Internal 246319
>
> If you can't find the time to do it right the first time, where will you
> find the time to do it again?
>
>
> Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/03/2007 02:57:26:
>
> > Hi Brian,
> >
> > That doesn't make sense to me- if the MEP has completed then the message
>
> > is arriving after everything has happened. The MEP would not have been
> > marked complete unless RM successfully delivered the message to the
> receiver.
> >
> > So if after that a message arrives referring to a completed operation
> then
> > we can reject it in addressing right away.
> >
> > Can you explain a scenario where someone like WS-RM will do anything
> > useful with it? And what will happen if there's no WS-RM etc. around at
> > all and this method doesn't catch this repeated message?
> >
> > Thanks,
> >
> > Sanjiva.
> >
> > Brian De Pradine wrote:
> > >
> > > Hello,
> > >
> > > Apologies for not making the intent clearer. We are not swallowing the
>
> > > message, but instead simply allowing it to continue on it's way
> through
> > > the flow. The idea is that we do not have enough information in the
> > > AddressingBasedDispatcher to determine that such messages are 'bad'.
> > > Instead we want to allow other layers such as WS-RM to see, and
> possibly
> > > handle, such duplicate messages.
> > >
> > > Cheers
> > >
> > > Brian DePradine
> > > Web Services Development
> > > IBM Hursley
> > > External +44 (0) 1962 816319 Internal 246319
> > >
> > > If you can't find the time to do it right the first time, where will
> you
> > > find the time to do it again?
> > >
> > >
> > > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 01/03/2007
> 01:47:46:
> > >
> > > > +1 but I'm confused why we'd remove this exception .. if someone
> sends a
> > > > response message again we should be saying "nope been there done
> that
> > > > already" back to the sender. If you eat the exception and log it
> they
> > > have
> > > > no info. What is broken about the old code?
> > > >
> > > > Sanjiva.
> > > >
> > > > David Illsley wrote:
> > > > > Hi Brian,
> > > > > I think it's important that if this (message being swallowed) is
> > > > > happening, that we make it very obvous. What do you think about
> > > > > logging at a higher level than debug?
> > > > > David
> > > > >
> > > > > On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> > > > >> Author: pradine
> > > > >> Date: Wed Feb 28 09:43:07 2007
> > > > >> New Revision: 512869
> > > > >>
> > > > >> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> > > > >> Log:
> > > > >> Do something more useful than throw an exception.
> > > > >>
> > > > >> Modified:
> > > > >>
> > > > >>
> > > >
> > >
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > > java
> > > > >>
> > > > >>
> > > > >> Modified:
> > > > >>
> > > >
> > >
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > > java
> > > > >>
> > > > >> URL:
> > > > >> http://svn.apache.
> > > >
> > >
> >
> org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > > java?view=diff&rev=512869&r1=512868&r2=512869
> > > > >>
> > > > >>
> > > >
> > >
> >
> ==============================================================================
> > > > >>
> > > > >> ---
> > > > >>
> > > >
> > >
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > > java
> > > > >> (original)
> > > > >> +++
> > > > >>
> > > >
> > >
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > > java
> > > > >> Wed Feb 28 09:43:07 2007
> > > > >> @@ -137,16 +137,18 @@
> > > > >> log.debug(msgctx.getLogIDString()+"
> > > > >> "+Messages.getMessage("checkingrelatesto",
> > > > >> relatesTo));
> > > > >> }
> > > > >> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> > > > >> + if (relatesTo != null && !"".equals(relatesTo)) {
> > > > >> OperationContext operationContext =
> > > > >> msgctx.getConfigurationContext()
> > > > >>
> .getOperationContext(relatesTo);
> > > > >>
> > > > >> if (operationContext != null) {
> > > > >> if(operationContext.isComplete()){
> > > > >> - // If the dispatch happens because of
> the
> > > > >> RelatesTo and the mep is complete
> > > > >> - // we should throw a more descriptive
> fault.
> > > > >> - throw new
> > > > >> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> > > > >> + if(LoggingControl.debugLoggingAllowed&&
> > > > >> log.isDebugEnabled()){
> > > > >> + log.debug(msgctx.getLogIDString()+"
> > > > >> Operation context is marked as complete. Calling cleanup on
> it.");
> > > > >> + }
> > > > >> + operationContext.cleanup();
> > > > >> + return InvocationResponse.CONTINUE;
> > > > >> }
> > > > >>
> > > > >> msgctx.setAxisOperation(operationContext.getAxisOperation());
> > > > >> msgctx.setOperationContext
> (operationContext);
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> > > > >> For additional commands, e-mail: axis-cvs-help@ws.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sanjiva Weerawarana, Ph.D.
> > > > Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> > > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > > Director; Open Source Initiative; http://www.opensource.org/
> > > > Member; Apache Software Foundation; http://www.apache.org/
> > > > Visiting Lecturer; University of Moratuwa;
> http://www.cse.mrt.ac.lk/
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > /
> > > /
> > >
> > > /Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU/
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
>
> ------------------------------
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by David Illsley <da...@gmail.com>.
:-) I enjoy getting the credit for Brian's work.
David
On 07/03/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Thanks David! Definitely +1 for fixing this in Sandesha ..
>
> Sanjiva.
>
> Brian De Pradine wrote:
> >
> > Hi Sanjiva,
> >
> > If this problem can be fixed in the Sandesha layer that will be better
> > than the current fix. I will revert the changes.
> >
> > Cheers
> >
> > Brian DePradine
> > Web Services Development
> > IBM Hursley
> > External +44 (0) 1962 816319 Internal 246319
> >
> > If you can't find the time to do it right the first time, where will you
> > find the time to do it again?
> >
> >
> > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 05/03/2007 02:59:15:
> >
> > > Brian De Pradine wrote:
> > > >
> > > > In this scenario the server sends a response message to the client.
> > The
> > > > client then tries to send an acknowledgement to the server, but the
> > > > acknowledgement gets lost, for whatever reason. This means that the
> > > > WS-RM layer, in the server, will eventually time-out and send the
> > > > response message again. This time the client should send an
> > > > acknowledgement to cover both the original and the duplicate response
> > > > messages.
> > > >
> > > > This scenario is broken because the duplicate response never makes
> > it to
> > > > the WS-RM layer on the client side, because the
> > > > AddressingBasedDispatcher recognises it as a duplicate and throws an
> > > > exception instead. This means that the WS-RM layer never gets
> > driven to
> > > > send the second acknowledgement. The result is that the server will
> > > > simply keep sending duplicate responses forever (almost)!
> > > >
> > > > In order to get this scenario to work the AddressingBasedDispatcher
> > will
> > > > need to dispatch any duplicate messages as normal, instead of deciding
> > > > that they are 'bad' and throwing an exception. This will allow
> > WS-RM to
> > > > be easily added into the picture at any time. This also means that if
> > > > there is no WS-RM engaged then a service will potentially be driven
> > more
> > > > than once if there are duplicate messages (created by some other
> > means).
> > > > This shouldn't be a problem, however, because web services are
> > meant to
> > > > be stateless entities anyway :-) If you do happen to have a web
> > service
> > > > that is not stateless then you will need to engage WS-RM to ensure
> > that
> > > > it is not driven by duplicates.
> > >
> > > OK I understand the scenario but I'm -1 on this because it breaks normal
> > > users. You can't say that Web services are stateless and therefore
> > its ok
> > > to just let messages get delivered repeatedly violating our MEP concept!
> > >
> > > RM is a lower level thing than MEPS- its infrastructural. The MEP should
> > > not be marked complete if the message hasn't been received to the
> > > satisfaction of the lower level.
> > >
> > > If what Chamikara suggests will fix this for RM that's great but no
> > matter
> > > what this change is not acceptable because its breaking the
> > definition of
> > > a MEP. Think of a TCP analogy: TCP users a protocol similar to RM to
> > > resend packets. Anyone who implements something like HTTP over TCP
> > doesn't
> > > need to be concerned with the response being delivered twice!!
> > >
> > > Sanjiva.
> > > --
> > > Sanjiva Weerawarana, Ph.D.
> > > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > Director; Open Source Initiative; http://www.opensource.org/
> > > Member; Apache Software Foundation; http://www.apache.org/
> > > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> >
> >
> >
> >
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Thanks David! Definitely +1 for fixing this in Sandesha ..
Sanjiva.
Brian De Pradine wrote:
>
> Hi Sanjiva,
>
> If this problem can be fixed in the Sandesha layer that will be better
> than the current fix. I will revert the changes.
>
> Cheers
>
> Brian DePradine
> Web Services Development
> IBM Hursley
> External +44 (0) 1962 816319 Internal 246319
>
> If you can't find the time to do it right the first time, where will you
> find the time to do it again?
>
>
> Sanjiva Weerawarana <sa...@opensource.lk> wrote on 05/03/2007 02:59:15:
>
> > Brian De Pradine wrote:
> > >
> > > In this scenario the server sends a response message to the client.
> The
> > > client then tries to send an acknowledgement to the server, but the
> > > acknowledgement gets lost, for whatever reason. This means that the
> > > WS-RM layer, in the server, will eventually time-out and send the
> > > response message again. This time the client should send an
> > > acknowledgement to cover both the original and the duplicate response
> > > messages.
> > >
> > > This scenario is broken because the duplicate response never makes
> it to
> > > the WS-RM layer on the client side, because the
> > > AddressingBasedDispatcher recognises it as a duplicate and throws an
> > > exception instead. This means that the WS-RM layer never gets
> driven to
> > > send the second acknowledgement. The result is that the server will
> > > simply keep sending duplicate responses forever (almost)!
> > >
> > > In order to get this scenario to work the AddressingBasedDispatcher
> will
> > > need to dispatch any duplicate messages as normal, instead of deciding
> > > that they are 'bad' and throwing an exception. This will allow
> WS-RM to
> > > be easily added into the picture at any time. This also means that if
> > > there is no WS-RM engaged then a service will potentially be driven
> more
> > > than once if there are duplicate messages (created by some other
> means).
> > > This shouldn't be a problem, however, because web services are
> meant to
> > > be stateless entities anyway :-) If you do happen to have a web
> service
> > > that is not stateless then you will need to engage WS-RM to ensure
> that
> > > it is not driven by duplicates.
> >
> > OK I understand the scenario but I'm -1 on this because it breaks normal
> > users. You can't say that Web services are stateless and therefore
> its ok
> > to just let messages get delivered repeatedly violating our MEP concept!
> >
> > RM is a lower level thing than MEPS- its infrastructural. The MEP should
> > not be marked complete if the message hasn't been received to the
> > satisfaction of the lower level.
> >
> > If what Chamikara suggests will fix this for RM that's great but no
> matter
> > what this change is not acceptable because its breaking the
> definition of
> > a MEP. Think of a TCP analogy: TCP users a protocol similar to RM to
> > resend packets. Anyone who implements something like HTTP over TCP
> doesn't
> > need to be concerned with the response being delivered twice!!
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hi Sanjiva,
If this problem can be fixed in the Sandesha layer that will be better
than the current fix. I will revert the changes.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Sanjiva Weerawarana <sa...@opensource.lk> wrote on 05/03/2007 02:59:15:
> Brian De Pradine wrote:
> >
> > In this scenario the server sends a response message to the client.
The
> > client then tries to send an acknowledgement to the server, but the
> > acknowledgement gets lost, for whatever reason. This means that the
> > WS-RM layer, in the server, will eventually time-out and send the
> > response message again. This time the client should send an
> > acknowledgement to cover both the original and the duplicate response
> > messages.
> >
> > This scenario is broken because the duplicate response never makes it
to
> > the WS-RM layer on the client side, because the
> > AddressingBasedDispatcher recognises it as a duplicate and throws an
> > exception instead. This means that the WS-RM layer never gets driven
to
> > send the second acknowledgement. The result is that the server will
> > simply keep sending duplicate responses forever (almost)!
> >
> > In order to get this scenario to work the AddressingBasedDispatcher
will
> > need to dispatch any duplicate messages as normal, instead of deciding
> > that they are 'bad' and throwing an exception. This will allow WS-RM
to
> > be easily added into the picture at any time. This also means that if
> > there is no WS-RM engaged then a service will potentially be driven
more
> > than once if there are duplicate messages (created by some other
means).
> > This shouldn't be a problem, however, because web services are meant
to
> > be stateless entities anyway :-) If you do happen to have a web
service
> > that is not stateless then you will need to engage WS-RM to ensure
that
> > it is not driven by duplicates.
>
> OK I understand the scenario but I'm -1 on this because it breaks normal
> users. You can't say that Web services are stateless and therefore its
ok
> to just let messages get delivered repeatedly violating our MEP concept!
>
> RM is a lower level thing than MEPS- its infrastructural. The MEP should
> not be marked complete if the message hasn't been received to the
> satisfaction of the lower level.
>
> If what Chamikara suggests will fix this for RM that's great but no
matter
> what this change is not acceptable because its breaking the definition
of
> a MEP. Think of a TCP analogy: TCP users a protocol similar to RM to
> resend packets. Anyone who implements something like HTTP over TCP
doesn't
> need to be concerned with the response being delivered twice!!
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Brian De Pradine wrote:
>
> In this scenario the server sends a response message to the client. The
> client then tries to send an acknowledgement to the server, but the
> acknowledgement gets lost, for whatever reason. This means that the
> WS-RM layer, in the server, will eventually time-out and send the
> response message again. This time the client should send an
> acknowledgement to cover both the original and the duplicate response
> messages.
>
> This scenario is broken because the duplicate response never makes it to
> the WS-RM layer on the client side, because the
> AddressingBasedDispatcher recognises it as a duplicate and throws an
> exception instead. This means that the WS-RM layer never gets driven to
> send the second acknowledgement. The result is that the server will
> simply keep sending duplicate responses forever (almost)!
>
> In order to get this scenario to work the AddressingBasedDispatcher will
> need to dispatch any duplicate messages as normal, instead of deciding
> that they are 'bad' and throwing an exception. This will allow WS-RM to
> be easily added into the picture at any time. This also means that if
> there is no WS-RM engaged then a service will potentially be driven more
> than once if there are duplicate messages (created by some other means).
> This shouldn't be a problem, however, because web services are meant to
> be stateless entities anyway :-) If you do happen to have a web service
> that is not stateless then you will need to engage WS-RM to ensure that
> it is not driven by duplicates.
OK I understand the scenario but I'm -1 on this because it breaks normal
users. You can't say that Web services are stateless and therefore its ok
to just let messages get delivered repeatedly violating our MEP concept!
RM is a lower level thing than MEPS- its infrastructural. The MEP should
not be marked complete if the message hasn't been received to the
satisfaction of the lower level.
If what Chamikara suggests will fix this for RM that's great but no matter
what this change is not acceptable because its breaking the definition of
a MEP. Think of a TCP analogy: TCP users a protocol similar to RM to
resend packets. Anyone who implements something like HTTP over TCP doesn't
need to be concerned with the response being delivered twice!!
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hi Sanjiva,
I will try my best. :-)
Here is a WS-RM scenario that currently doesn't work,
Client Server
------ ------
| 1. Response |
| <----------------------------------------- |
| 2. Ack |
| ---------------------------->X |
| 3. Duplicate |
| <----------------------------------------- |
| 4. Ack |
| -----------------------------------------> |
| |
| |
In this scenario the server sends a response message to the client. The
client then tries to send an acknowledgement to the server, but the
acknowledgement gets lost, for whatever reason. This means that the WS-RM
layer, in the server, will eventually time-out and send the response
message again. This time the client should send an acknowledgement to
cover both the original and the duplicate response messages.
This scenario is broken because the duplicate response never makes it to
the WS-RM layer on the client side, because the AddressingBasedDispatcher
recognises it as a duplicate and throws an exception instead. This means
that the WS-RM layer never gets driven to send the second acknowledgement.
The result is that the server will simply keep sending duplicate responses
forever (almost)!
In order to get this scenario to work the AddressingBasedDispatcher will
need to dispatch any duplicate messages as normal, instead of deciding
that they are 'bad' and throwing an exception. This will allow WS-RM to be
easily added into the picture at any time. This also means that if there
is no WS-RM engaged then a service will potentially be driven more than
once if there are duplicate messages (created by some other means). This
shouldn't be a problem, however, because web services are meant to be
stateless entities anyway :-) If you do happen to have a web service that
is not stateless then you will need to engage WS-RM to ensure that it is
not driven by duplicates.
I hope this helps.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/03/2007 02:57:26:
> Hi Brian,
>
> That doesn't make sense to me- if the MEP has completed then the message
> is arriving after everything has happened. The MEP would not have been
> marked complete unless RM successfully delivered the message to the
receiver.
>
> So if after that a message arrives referring to a completed operation
then
> we can reject it in addressing right away.
>
> Can you explain a scenario where someone like WS-RM will do anything
> useful with it? And what will happen if there's no WS-RM etc. around at
> all and this method doesn't catch this repeated message?
>
> Thanks,
>
> Sanjiva.
>
> Brian De Pradine wrote:
> >
> > Hello,
> >
> > Apologies for not making the intent clearer. We are not swallowing the
> > message, but instead simply allowing it to continue on it's way
through
> > the flow. The idea is that we do not have enough information in the
> > AddressingBasedDispatcher to determine that such messages are 'bad'.
> > Instead we want to allow other layers such as WS-RM to see, and
possibly
> > handle, such duplicate messages.
> >
> > Cheers
> >
> > Brian DePradine
> > Web Services Development
> > IBM Hursley
> > External +44 (0) 1962 816319 Internal 246319
> >
> > If you can't find the time to do it right the first time, where will
you
> > find the time to do it again?
> >
> >
> > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 01/03/2007
01:47:46:
> >
> > > +1 but I'm confused why we'd remove this exception .. if someone
sends a
> > > response message again we should be saying "nope been there done
that
> > > already" back to the sender. If you eat the exception and log it
they
> > have
> > > no info. What is broken about the old code?
> > >
> > > Sanjiva.
> > >
> > > David Illsley wrote:
> > > > Hi Brian,
> > > > I think it's important that if this (message being swallowed) is
> > > > happening, that we make it very obvous. What do you think about
> > > > logging at a higher level than debug?
> > > > David
> > > >
> > > > On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> > > >> Author: pradine
> > > >> Date: Wed Feb 28 09:43:07 2007
> > > >> New Revision: 512869
> > > >>
> > > >> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> > > >> Log:
> > > >> Do something more useful than throw an exception.
> > > >>
> > > >> Modified:
> > > >>
> > > >>
> > >
> >
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > java
> > > >>
> > > >>
> > > >> Modified:
> > > >>
> > >
> >
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > java
> > > >>
> > > >> URL:
> > > >> http://svn.apache.
> > >
> >
>
org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > java?view=diff&rev=512869&r1=512868&r2=512869
> > > >>
> > > >>
> > >
> >
>
==============================================================================
> > > >>
> > > >> ---
> > > >>
> > >
> >
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > java
> > > >> (original)
> > > >> +++
> > > >>
> > >
> >
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > > java
> > > >> Wed Feb 28 09:43:07 2007
> > > >> @@ -137,16 +137,18 @@
> > > >> log.debug(msgctx.getLogIDString()+"
> > > >> "+Messages.getMessage("checkingrelatesto",
> > > >> relatesTo));
> > > >> }
> > > >> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> > > >> + if (relatesTo != null && !"".equals(relatesTo)) {
> > > >> OperationContext operationContext =
> > > >> msgctx.getConfigurationContext()
> > > >> .getOperationContext(relatesTo);
> > > >>
> > > >> if (operationContext != null) {
> > > >> if(operationContext.isComplete()){
> > > >> - // If the dispatch happens because of
the
> > > >> RelatesTo and the mep is complete
> > > >> - // we should throw a more descriptive
fault.
> > > >> - throw new
> > > >> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> > > >> + if(LoggingControl.debugLoggingAllowed
&&
> > > >> log.isDebugEnabled()){
> > > >> + log.debug(msgctx.getLogIDString()+"
> > > >> Operation context is marked as complete. Calling cleanup on
it.");
> > > >> + }
> > > >> + operationContext.cleanup();
> > > >> + return InvocationResponse.CONTINUE;
> > > >> }
> > > >>
> > > >> msgctx.setAxisOperation(operationContext.getAxisOperation());
> > > >> msgctx.setOperationContext(operationContext);
> > > >>
> > > >>
> > > >>
> > > >>
---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: axis-cvs-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > Sanjiva Weerawarana, Ph.D.
> > > Founder & Director; Lanka Software Foundation;
http://www.opensource.lk/
> > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > Director; Open Source Initiative; http://www.opensource.org/
> > > Member; Apache Software Foundation; http://www.apache.org/
> > > Visiting Lecturer; University of Moratuwa;
http://www.cse.mrt.ac.lk/
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU/
> >
> >
> >
> >
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Brian,
That doesn't make sense to me- if the MEP has completed then the message
is arriving after everything has happened. The MEP would not have been
marked complete unless RM successfully delivered the message to the receiver.
So if after that a message arrives referring to a completed operation then
we can reject it in addressing right away.
Can you explain a scenario where someone like WS-RM will do anything
useful with it? And what will happen if there's no WS-RM etc. around at
all and this method doesn't catch this repeated message?
Thanks,
Sanjiva.
Brian De Pradine wrote:
>
> Hello,
>
> Apologies for not making the intent clearer. We are not swallowing the
> message, but instead simply allowing it to continue on it's way through
> the flow. The idea is that we do not have enough information in the
> AddressingBasedDispatcher to determine that such messages are 'bad'.
> Instead we want to allow other layers such as WS-RM to see, and possibly
> handle, such duplicate messages.
>
> Cheers
>
> Brian DePradine
> Web Services Development
> IBM Hursley
> External +44 (0) 1962 816319 Internal 246319
>
> If you can't find the time to do it right the first time, where will you
> find the time to do it again?
>
>
> Sanjiva Weerawarana <sa...@opensource.lk> wrote on 01/03/2007 01:47:46:
>
> > +1 but I'm confused why we'd remove this exception .. if someone sends a
> > response message again we should be saying "nope been there done that
> > already" back to the sender. If you eat the exception and log it they
> have
> > no info. What is broken about the old code?
> >
> > Sanjiva.
> >
> > David Illsley wrote:
> > > Hi Brian,
> > > I think it's important that if this (message being swallowed) is
> > > happening, that we make it very obvous. What do you think about
> > > logging at a higher level than debug?
> > > David
> > >
> > > On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> > >> Author: pradine
> > >> Date: Wed Feb 28 09:43:07 2007
> > >> New Revision: 512869
> > >>
> > >> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> > >> Log:
> > >> Do something more useful than throw an exception.
> > >>
> > >> Modified:
> > >>
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >>
> > >>
> > >> Modified:
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >>
> > >> URL:
> > >> http://svn.apache.
> >
> org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java?view=diff&rev=512869&r1=512868&r2=512869
> > >>
> > >>
> >
> ==============================================================================
> > >>
> > >> ---
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >> (original)
> > >> +++
> > >>
> >
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> > java
> > >> Wed Feb 28 09:43:07 2007
> > >> @@ -137,16 +137,18 @@
> > >> log.debug(msgctx.getLogIDString()+"
> > >> "+Messages.getMessage("checkingrelatesto",
> > >> relatesTo));
> > >> }
> > >> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> > >> + if (relatesTo != null && !"".equals(relatesTo)) {
> > >> OperationContext operationContext =
> > >> msgctx.getConfigurationContext()
> > >> .getOperationContext(relatesTo);
> > >>
> > >> if (operationContext != null) {
> > >> if(operationContext.isComplete()){
> > >> - // If the dispatch happens because of the
> > >> RelatesTo and the mep is complete
> > >> - // we should throw a more descriptive fault.
> > >> - throw new
> > >> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> > >> + if(LoggingControl.debugLoggingAllowed &&
> > >> log.isDebugEnabled()){
> > >> + log.debug(msgctx.getLogIDString()+"
> > >> Operation context is marked as complete. Calling cleanup on it.");
> > >> + }
> > >> + operationContext.cleanup();
> > >> + return InvocationResponse.CONTINUE;
> > >> }
> > >>
> > >> msgctx.setAxisOperation(operationContext.getAxisOperation());
> > >> msgctx.setOperationContext(operationContext);
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-cvs-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hello,
Apologies for not making the intent clearer. We are not swallowing the
message, but instead simply allowing it to continue on it's way through
the flow. The idea is that we do not have enough information in the
AddressingBasedDispatcher to determine that such messages are 'bad'.
Instead we want to allow other layers such as WS-RM to see, and possibly
handle, such duplicate messages.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Sanjiva Weerawarana <sa...@opensource.lk> wrote on 01/03/2007 01:47:46:
> +1 but I'm confused why we'd remove this exception .. if someone sends a
> response message again we should be saying "nope been there done that
> already" back to the sender. If you eat the exception and log it they
have
> no info. What is broken about the old code?
>
> Sanjiva.
>
> David Illsley wrote:
> > Hi Brian,
> > I think it's important that if this (message being swallowed) is
> > happening, that we make it very obvous. What do you think about
> > logging at a higher level than debug?
> > David
> >
> > On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> >> Author: pradine
> >> Date: Wed Feb 28 09:43:07 2007
> >> New Revision: 512869
> >>
> >> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> >> Log:
> >> Do something more useful than throw an exception.
> >>
> >> Modified:
> >>
> >>
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> java
> >>
> >>
> >> Modified:
> >>
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> java
> >>
> >> URL:
> >> http://svn.apache.
>
org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> java?view=diff&rev=512869&r1=512868&r2=512869
> >>
> >>
>
==============================================================================
> >>
> >> ---
> >>
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> java
> >> (original)
> >> +++
> >>
>
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.
> java
> >> Wed Feb 28 09:43:07 2007
> >> @@ -137,16 +137,18 @@
> >> log.debug(msgctx.getLogIDString()+"
> >> "+Messages.getMessage("checkingrelatesto",
> >> relatesTo));
> >> }
> >> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> >> + if (relatesTo != null && !"".equals(relatesTo)) {
> >> OperationContext operationContext =
> >> msgctx.getConfigurationContext()
> >> .getOperationContext(relatesTo);
> >>
> >> if (operationContext != null) {
> >> if(operationContext.isComplete()){
> >> - // If the dispatch happens because of the
> >> RelatesTo and the mep is complete
> >> - // we should throw a more descriptive fault.
> >> - throw new
> >> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> >> + if(LoggingControl.debugLoggingAllowed &&
> >> log.isDebugEnabled()){
> >> + log.debug(msgctx.getLogIDString()+"
> >> Operation context is marked as complete. Calling cleanup on it.");
> >> + }
> >> + operationContext.cleanup();
> >> + return InvocationResponse.CONTINUE;
> >> }
> >>
> >> msgctx.setAxisOperation(operationContext.getAxisOperation());
> >> msgctx.setOperationContext(operationContext);
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-cvs-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 but I'm confused why we'd remove this exception .. if someone sends a
response message again we should be saying "nope been there done that
already" back to the sender. If you eat the exception and log it they have
no info. What is broken about the old code?
Sanjiva.
David Illsley wrote:
> Hi Brian,
> I think it's important that if this (message being swallowed) is
> happening, that we make it very obvous. What do you think about
> logging at a higher level than debug?
> David
>
> On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
>> Author: pradine
>> Date: Wed Feb 28 09:43:07 2007
>> New Revision: 512869
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
>> Log:
>> Do something more useful than throw an exception.
>>
>> Modified:
>>
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
>>
>>
>> Modified:
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
>>
>> URL:
>> http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java?view=diff&rev=512869&r1=512868&r2=512869
>>
>> ==============================================================================
>>
>> ---
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
>> (original)
>> +++
>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
>> Wed Feb 28 09:43:07 2007
>> @@ -137,16 +137,18 @@
>> log.debug(msgctx.getLogIDString()+"
>> "+Messages.getMessage("checkingrelatesto",
>> relatesTo));
>> }
>> - if ((relatesTo != null) && !"".equals(relatesTo)) {
>> + if (relatesTo != null && !"".equals(relatesTo)) {
>> OperationContext operationContext =
>> msgctx.getConfigurationContext()
>> .getOperationContext(relatesTo);
>>
>> if (operationContext != null) {
>> if(operationContext.isComplete()){
>> - // If the dispatch happens because of the
>> RelatesTo and the mep is complete
>> - // we should throw a more descriptive fault.
>> - throw new
>> AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
>> + if(LoggingControl.debugLoggingAllowed &&
>> log.isDebugEnabled()){
>> + log.debug(msgctx.getLogIDString()+"
>> Operation context is marked as complete. Calling cleanup on it.");
>> + }
>> + operationContext.cleanup();
>> + return InvocationResponse.CONTINUE;
>> }
>>
>> msgctx.setAxisOperation(operationContext.getAxisOperation());
>> msgctx.setOperationContext(operationContext);
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-cvs-help@ws.apache.org
>>
>>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
Posted by David Illsley <da...@gmail.com>.
Hi Brian,
I think it's important that if this (message being swallowed) is
happening, that we make it very obvous. What do you think about
logging at a higher level than debug?
David
On 28/02/07, pradine@apache.org <pr...@apache.org> wrote:
> Author: pradine
> Date: Wed Feb 28 09:43:07 2007
> New Revision: 512869
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=512869
> Log:
> Do something more useful than throw an exception.
>
> Modified:
> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
>
> Modified: webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
> URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java?view=diff&rev=512869&r1=512868&r2=512869
> ==============================================================================
> --- webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java (original)
> +++ webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java Wed Feb 28 09:43:07 2007
> @@ -137,16 +137,18 @@
> log.debug(msgctx.getLogIDString()+" "+Messages.getMessage("checkingrelatesto",
> relatesTo));
> }
> - if ((relatesTo != null) && !"".equals(relatesTo)) {
> + if (relatesTo != null && !"".equals(relatesTo)) {
> OperationContext operationContext =
> msgctx.getConfigurationContext()
> .getOperationContext(relatesTo);
>
> if (operationContext != null) {
> if(operationContext.isComplete()){
> - // If the dispatch happens because of the RelatesTo and the mep is complete
> - // we should throw a more descriptive fault.
> - throw new AxisFault(Messages.getMessage("duplicaterelatesto",relatesTo));
> + if(LoggingControl.debugLoggingAllowed && log.isDebugEnabled()){
> + log.debug(msgctx.getLogIDString()+" Operation context is marked as complete. Calling cleanup on it.");
> + }
> + operationContext.cleanup();
> + return InvocationResponse.CONTINUE;
> }
> msgctx.setAxisOperation(operationContext.getAxisOperation());
> msgctx.setOperationContext(operationContext);
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-cvs-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org