You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Saminda Abeyruwan <sa...@opensource.lk> on 2005/11/10 15:14:49 UTC
[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
Re: [Axis2] Imporvement in Axis2 transport layer
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi All,
Please see my comments below,
On 11/11/05, Srinath Perera <he...@gmail.com> 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. 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
Re: [Axis2] Imporvement in Axis2 transport layer
Posted by Srinath Perera <he...@gmail.com>.
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 <ja...@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 <ja...@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" <sa...@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
Re: [Axis2] Imporvement in Axis2 transport layer
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
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 <ja...@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" <sa...@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
Re: [Axis2] Imporvement in Axis2 transport layer
Posted by Ajith Ranabahu <aj...@gmail.com>.
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. 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)
Jaliya, I'm a bit 0- on the idea of having a single listener. It'll make
things hard when the listner needs to be timed out! 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 <ja...@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" <sa...@opensource.lk>
> To: <ax...@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
Re: [Axis2] Imporvement in Axis2 transport layer
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
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" <sa...@opensource.lk>
To: <ax...@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
>