You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2007/03/05 01:42:46 UTC
Re: svn commit: r512869 - /webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/engine/AddressingBasedDispatcher.java
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>.
(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
>
>