Please see my comments below,
On 11/11/05, Srinath Perera <[EMAIL PROTECTED]> wrote:
+1. I also believe this is the way for requests that take a long time to process.
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. 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). 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 (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
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. 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). 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 (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
