axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <>
Subject Re: [Axis2] Imporvement in Axis2 transport layer
Date Thu, 10 Nov 2005 15:09:09 GMT

I have been thinking of this problem and came up with this possible 

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



----- Original Message ----- 
From: "Saminda Abeyruwan" <>
To: <>
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

View raw message