(sorry, there was a mistake in the previous post) On 3/5/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Matt, Thanks for the clarification. Please see below. On 3/4/07, Matthew Lovett <[EMAIL PROTECTED] > wrote: > > "Chamikara Jayalath" < [EMAIL PROTECTED]> 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
