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.
>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:
<
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
