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
