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 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
