Re:[axis2] in scope="soapsession" how to set ConfigContextTimeoutInterval OR LastTouchedTime to 0 programmatically

[Luciana Moreira Signed by - PrivaSphere AG <si...@privasphere.com>]

Hello everyone,

In our project we have the exact same problem as the one described by 
Josef in the e-mail below. I did not find any replies to his message. 
Has this topic been addressed somewhere else? Is there a solution to 
enforce soap session termination?

Thx

=====================================================

Subject: 	[axis2] in scope="soapsession" how to set 
ConfigContextTimeoutInterval OR LastTouchedTime to 0 programmatically 
<http://markmail.org/message/4jyj7hcpomfcnoux> 	permalink 
<http://markmail.org/message/4jyj7hcpomfcnoux>
From: 	Stadelmann Josef (jose...@axa-winterthur.ch)
Date: 	Oct 7, 2010 12:37:23 am
List: 	org.apache.ws.axis-user


In scope="soapsession" the liefe-time of the service-object ( a real 
instance for long lasting sessions ) is only controlled in axis2.xml by 
a timeout value

<!-- This will give out the timout of the configuration contexts, in 
milliseconds --> <parameter 
name="ConfigContextTimeoutInterval">30000</parameter>

We use this value as beeing 28'800'000 acounting for 8 hours. The user 
logs in and keeps his statefull server session open for the rest of his 
8 working hours, also some heavy calculation task/calls run very long, 
and our 25 year old LEGACY servers are not made for any form of 
asynchronous communication and callbacks.

The question/problem I have is: how can we make that our service-objects 
go away when the session gets closed or is no longer used in case of a 
fatal error in the server?

We would need to be able to

a) resetting <parameter 
name="ConfigContextTimeoutInterval">0</parameter> b) or call somehow

public void setLastTouchedTime(long t) { lastTouchedTime = t; }

and set LastTouchedTime to 0 to achive the effect that when 
Sessionmanager.cleanupServiceGroupContexts() is called next times, it 
triggers the timeout

if ((currentTime - sessionContext.getLastTouchedTime()) > 
sessionContext.sessionContextTimeoutInterval)

and then as a followup cleanly does it.remove(); and the rest of the 
required cleanup cycles, what ever they are right now.

As we keep a reference to the sessionContext as passed by init() we 
could easy call the proper code and cleanup the timeout and tochtime 
values for our own object.

This would force that our service-objects destroy() routine would be 
called and that we have a means of cleaning up resources keep under 
axis2 control and lock when a long lasting session shall terminate as 
abort() or as close().

I could sniff in the code into axis2 kernel and have the issue to 
backintegrate the change, but maybe someone has a better idea.

Josef



----------
This message has been signed by the PrivaSphere Mail Signature Service.