axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: [Axis2] Imporvement in Axis2 transport layer
Date Thu, 10 Nov 2005 19:00:41 GMT
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 <jaliya@opensource.lk> wrote:
>
> Hi Ajith see the comments,
>
> ----- Original Message -----
>
> From: Ajith Ranabahu
> To: axis-dev@ws.apache.org
> 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 <jaliya@opensource.lk> 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" <saminda@opensource.lk>
> > To: < axis-dev@ws.apache.org>
> > 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

Mime
View raw message