Hi Guys; If the server side service impl processing is expensive the AsyncMessage Receivers should be used! Does it fix the trouble?
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 On 11/10/05, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > > Hi Ajith see the comments, > > ----- Original Message ----- > > From: Ajith Ranabahu > To: [email protected] > Sent: Thursday, November 10, 2005 11:27 AM > Subject: Re: [Axis2] Imporvement in Axis2 transport layer > > > Hi all, > I've noticed this behavior of the transport during the recent interop tests > with Microsoft. Out RM interop tests work nicely but the client keeps on > listening even after the 202 for the terminate sequence message. We should > have a way to tell the listener to shut down at somepoint and in the case of > RM, it would be the 202 for the terminate sequence. (Oh BTW the listener > should be configurable according to the policy too. > > The listener that I am suggesing is merely a transport listner and have no > idea about policy stuff. Handlers should be configured according to the > policy in the Axis2 engine and the listener simply accepts transport level > messages and hand over them to some acceptor, whcich will then invokes an > engine with proper handlers according to the policy. > > If you can have a look at the following WSDL > http://131.107.72.15/ReliableMessaging_Service_Indigo/ReliableRequestReplyDual.svc?wsdl > you'll see the policy assertion that says about the listener timeout) > > >Listener time out will affect only to whcih incoming enpoint or RMSequence > that we are listening to. The single listener will keep on listening but > will not do anything after time outs. > > Jaliya, I'm a bit 0- on the idea of having a single listener. > > >In the current architecture, if we need to run several client instances (on > separate JVMs) in a given machine we keep on generating the port numbers for > the listeners. I don't think this will be a feasible option when we are > inside a network with firewalls. Just consider how we can open these ports > for remote interop tests. > > but if we have a fixed listner port for the entire system then we can give > pemissions to this port and let all client instances to commuincate with > this. > > It'll make things hard when the listner needs to be timed out! > This time out is different to what I explained in the single listener > concept. > > > Instead what I see as appropriate is a mechanism to create listners passing > a configuration (which ofcourse includes the timeout and other stuff) and > the listener dies down after the given interval. > > thoughts ? > > > On 11/10/05, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have been thinking of this problem and came up with this possible > > improvement > > > > In the client side we can have a single message listener(it can do > sending > > as well) registered as a service or background process for the entire > > system. > > So it will be an axis2 message listener for that machine. > > We will introduce new transport which will just write the out going > messages > > to the queue(or database) without worrying about the actual sending of it. > > Our agent will continuously monitor this queue(or database) and send any > > message in the outgoing queue and when ever a response is present it will > be > > put them into the incoming queue. > > Now if the service invocation is time consuming, then user can select this > > transport and let the request to be sent. Later the client application can > > check the queue for any responses that it was expecting.( this can be in > > different instance of the client application, the only information it > needs > > is the correlation information) > > > > One other improvement is to send the messages using the normal transport > and > > write the correlation information to the queue so if there are no > responses > > for an INOUT mep then it can set some flag in the message context and let > it > > return. > > Then the Call will decide whether to wait or whether to inform the user > that > > the messages will take time. > > In any case, user can retrieve responses using the listener. > > > > There can be other improvements on this idea, so please comment. > > > > Thanks, > > > > Jaliya > > > > > > > > ----- Original Message ----- > > From: "Saminda Abeyruwan" <[EMAIL PROTECTED]> > > To: < [email protected]> > > Sent: Thursday, November 10, 2005 9:14 AM > > Subject: [Axis2] Imporvement in Axis2 transport layer > > > > > > > Hi all, > > > > > > My concern is regarding complete async message invocation. As my > > > understaning of the transport mechanism, during async duel invocation, > > > sender {HttpClient} expect 202 from server. Now the "out" stream for > this > > > at server side return when MessageReceiver returns and when doPost() > {if > > > it is servlet case}method returns. At one point in server side > > > CommonsHttpTrasnsportSender will create an another HttpClient and send > the > > > response due "reply-to" is not anonymus. > > > > > > Now assume a "time eating" service hangs and does not allow the MR to > > > return, then at client side instead of getting 202, it will time out > {at > > > sometime}. Sometimes later the response might come to listener. But the > > > timeout is not Runtime exception and the client will exit even though we > > > have a response. > > > > > > If we can correct this scenario, "there may be mediators which take a > > > long time to process" will come handy with the development of Synapse, > > > with async invocation. > > > > > > How can we overcome this problem. > > > > > > Thanks > > > > > > Saminda > > > > > > > > > > > > > -- > Ajith Ranabahu
