Hi Chamikara, Please see my comments below.
Thanks, Jaliya ----- Original Message ----- From: Chamikara Jayalath To: [email protected] Sent: Thursday, November 10, 2005 9:18 PM Subject: Re: [Axis2] Imporvement in Axis2 transport layer Hi All, Please see my comments below, On 11/11/05, Srinath Perera <[EMAIL PROTECTED]> wrote: Hi Guys; If the server side service impl processing is expensive the AsyncMessage Receivers should be used! Does it fix the trouble? +1. I also believe this is the way for requests that take a long time to process. It allow user to register a callback too, or the Message Receiver can add the message to a Queue and return as Jaliya suggest. In any case I believe this has nothing do with Axis2 than having a Async Message Receiver Srinath Going to the descussion on client listners, I also believe that having several listners in the client side can be troublesome. Mainly this can cause firewall issues (as Jaliya mentioned). Also IMO this feels like a concept that cousume too many resources at the client side (Axis2 client will have to open several ports at the client side). A listner with minimum information (no Policy etc.) and simply wait for requests and pass it to an AxisEngine, looks better to me. But as Ajith mentioned this concept also has a major problem. That is when to timeout. >>The listener should not worry about the time outs, it will upto the module >>who needs timings This listner will just accept any incoming messages. It >>can be improved to attach timouts for a given message sequence as well. One solution is to make the client Listner a service (as Jaliya mentioned). But this means that Axis2 client does not really exit even though the client programs exists (Axis2 client will leave an listning agent behind). This also does not feel very nice. Generally, any client program (not only in Axis2) is expected to clear everything it did after the program exists (correct me if I'm wrong). >>This can be the case if we start this listener automatically without >>knowing to the user. If we ask the user to start the Axis2 client listener >>using some command or ask them to start as we do for some server then we >>don't need to worry about stopping it. In anycase the long running service invocations (if the response takes time and need a listener) then it is better to start somehting that the user manully start other than having some automatic listener in a port. But with this concept, Axis2 client will keep a port open. (later the users will wonder why some other program gives a bind exception for port xxxx even after the Axis2 client exist). My openion is that we should go for a single client side listner, that is not a service. But how can we time it ou?. In the case of RM this is the time the RM Module send and receive all necessary Terminate Sequence messages >>Just attach the concept of time out to the listener( the listener that we >>use now or the listener that we talk about) and the sender and set the >>timeouts with the sequence infomation.It will fix the problem. (or the inactivity timeout, if this does not work properly) . But there can be some other module which has its own timeout value. So what I beleive is that this timeout property should be a global property of the Configuration Context which can be adjusted by each module. But it should be adjusted only if the value a module is proposing is larger than the value that has been already set by some other module (may be there should be a method that intelligently does this). The Axis2 client listner will only keep looking a this property. If the current time is larger that the value of the timeOut property the tranport will stop listining and exit.And the client program may exit too. Comments ???? Thanx, Chamikara
