axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Axis2] Imporvement in Axis2 transport layer
Date Sat, 12 Nov 2005 06:28:16 GMT
Hi Chamikara and all,

I accept that we need time outs, but why can't we do it from modules. Keep
the listener or the sender completely out of the notion of timings . Think
it as a pure transport listener. It is job is to listen for messages
coming to this endpoint and putting them to some pre-configured queue. (or

As you have mentioned since we have different timing requirements we
should allow the user to start a separate service (listener) and to
proceed with his invocations. Each module will keep the timings and work
with this single listener.

IMHO, user stopping the client at some undesired point in time is similar
to somebody shutting down some server all of a sudden. In that case also
if we have RM the communication will be reliable, if they start it again
(then the listener need the persistent storage) but I think solving this
problem with definite way is better than trying to synchronize various
timing needs of different modules.

One that advantage is we can configure this listener using the transport
handler, say, we configured the listener to be a web service (in a
scenario where web service becomes the client) then we don't need to start
separate client side listener all. Remember we support this in Sandesha
1.0 as well.
IMHO, these will be common usages of web services as they are used more in
business integrations.



----- Original Message -----
From: Chamikara Jayalath
Sent: Friday, November 11, 2005 2:34 AM
Subject: Re: [Axis2] Imporvement in Axis2 transport layer

Hi Jaliya,all,

Well, what I was proposing is a way to generalize the listner timeout
concept. Suppose both RM and Transaction modules are there. How do we
decide when to timeout. If it is just one module (e.g. RM) it can always
be decided an the listner can be informed. But this is not the case

Out of the discussion I see two main ways to achieve this. Both will work.

1. Make client listner a seperate service, It is up to the client to
exacly say when to start and when to stop the listner. If he stop it
wrongly some modules may now work correctly.

2. Make the client unaware of the time the listner ger stated and it get
This cannot be done without getting some information from each module.
(because only each module knows when its task end).

One way to implement the second approach is as follows.

There can be a global Map that has timeout information.
Each entry of the Map will be moduleName->whenToTimeout.
If there is not entry, the listner will timeout when the user say
Each module is allowed to update its 'whenTotimeOut' value but not of others.
What will actually affect is the largest one.

If we go for the RM case this is how it will work. In the begining of each
sequence the RM module  will update its timeout entry to
currenttime+inactivityTimeOut. But if the RM module feels that all of its
sequences ended (before the inctivitytimeout). It will update its MAP
entry to currenttime.

The listner will timeout when two conditions are satisfied.
1. The user has called call.close ()
2. The time proposed by all the modules (in the global MAP) , has been


On 11/11/05, <> wrote:
Hi Chamikara,

Please see my comments below.


----- Original Message -----
From: Chamikara Jayalath
Sent: Thursday, November 10, 2005 9:18 PM
Subject: Re: [Axis2] Imporvement in Axis2 transport layer

Hi All,

Please see my comments below,

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.

>>The listener should not worry about the time outs, it will upto the module
>>who needs timings This listner will just accept any incoming messages. It
>>can be improved to attach timouts for a given message sequence as well.

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

>>This can be the case if we start this listener automatically without
>>knowing to the user. If we ask the user to start the Axis2 client listener
>>using some command or ask them to start as we do for some server then we
>>don't need to worry about stopping it.
In anycase the long running service invocations (if the response takes time
and need a listener) then it is better to start somehting that the user
manully start other than having some automatic listener in a port.

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

>>Just attach the concept of time out to the listener( the listener that we
>>use now or the listener that we talk about) and the sender and set the
>>timeouts with the sequence infomation.It will fix the problem.

(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 ????


View raw message