I've been having the same issue.  I traced through the axis2 source and found 
the following:

1) Axis2 has a ConfigContextTimeoutInterval parameter in axis2.xml that by 
default is set to 30 with a comment stating this is in seconds.
2) Whenever the axis2.apache.axis2.context.ConfigurationContext registers a new 
ServiceGroupContext (resgisterServiceGroupContext), it adds the servicegroupid 
to a hashmap (serviceGroupContextMap), then "cleans-up" the hashmap using the 
following logic:

A timeout has occurred if currentTime - 
serviceGroupContext.getLastTouchedTime() > ConfigContextTimeoutInterval

The issue is that currentTime and lastTouchedTime are measured in millisecs 
(they are longs), whereas ConfigContextTimeout is treated as seconds (simply 
because the value in the axis2.xml is entered as secs). Therefore axis2 always 
thinks that context has timed-out and removes it.  

My solution was to modify the axis2.xml ConfigContextTimeoutInterval 
(ie. multiply it by 1000).  Looks like this was intended to be millisecs based 
on these lines of code from ConfigurationContext:

// current time out interval is 30 secs. Need to make this configurable
    private long serviceGroupContextTimoutInterval = 30 * 1000;

I think that in the implementation of the configurable timeout the 
documentation just didn't get updated.    


-----Original Message-----
From: Stadelmann Josef [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 05, 2007 11:28 AM
To: axis-user@ws.apache.org
Subject: AW: AW: sesion managment, scope=soapsession

Hi Deepal,

See my coment below +++>

-----Ursprüngliche Nachricht-----
Von: Deepal Jayasinghe [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 12. Dezember 2006 06:37
An: axis-user@ws.apache.org
Betreff: Re: AW: sesion managment, scope=soapsession


Hi  Stadelmann ;

>
>My client #1 runs continously, and sends arround 40 msg a second to the 
>server. 
>When the second client starts, cline t#1 is still sending messages and so we 
>do 
>not have a time-out condition. client #1 never times out.
>
>BUT as I decribe, using the code shown, when client #2 starts 
>MyService.destroy() 
>is called followed by MyService.init() which has the effect that client #1 
>fails 
>thereafter with an "invalid group context id exception"
>  
>
hmmm, can you please help me to re-create the problem. If you can send
me the sample services and clients that will be very helpful for me to
fix the issue.

>
>I would appreciate an example on how to have a scenario as I describe.
>When I read literature about tomcat, retriving a session object from the 
>clients request object, it seems that internals are figuring out which client 
>is calling and the rigth session object which acts as data store for the
>session is returned/created. 
>
>How is that with AXIS2-1.1?
>  
>
Will write a sample soon .
+++> Do you have an example now showing how to maintain statefull session 
objects?




>When the MyService Object gets created I store the creation time for the
>instance in a instance variable. And when multiple clients run without
>scope=soapsession set, all clients return the same time stamp. So that
>means for me! client #1 makes axis2 creating a first instance of a class,
>and places the creation timestamp.
>  
>
That can not happen , there should be a separate service impl class for
each client, Im 100% sure about that since I have tested that. :)

+++> and what happens if the service class or variables such as the 
time stamp are defined static. I have just now read a book about the Java Nativ 
Interface


The Java programming language supports two kinds of fields. Each instance of a
class has its own copy of instance fields of the class, whereas all instances 
of 
a class share the static fields of a class.


I think this answers why my time stamp, which was implemented as a static field,
returnes to each client the same date/time, the time it was last overwritten
when a instance gets created.


NOTE: Instances migth still be separate and be running in different threads but
as long as the time stamp field is static, each class returns to each related
client the same time stamp what ever value it is.
<++++










>This is called an object, and client #2 sends his message to the same instance
>the same object. When the call to client 2 returns, client #2 finds the same 
>time stamp as client #1 has. But when client #2 starts 10 seconds after client 
>#1,
>I would expect that client #2 has a different object-creation-timestamp
>then client #1 unless we talk to the same instance (which I cant use).
>Josef
>  
>
Are u keeping your value as a static ? I mean are u storing your value
in a static variable  ?

+++> I have answered this question with yes, but I did not realise until now
the difference of private static and private fields of a class.
<+++



>Again - my clients 1 to 20 do continously send messages, each client in
>its thread - I am using NetBeans and I am just launching more then one
>client. So each client is fully busy sending. But each client gets 
>responses from the same server object instance. And we have not a time-out
>condition as each client continously sends. Once we come to real clients
>where usesers invoke messages we wil care about timeouts. But as long as
>client code jsut loops in a for() we do not have time-outs, even not with
>20 sessions, but in our example using scope=soapsession, we do not get that
>far, as client #1 runs until client #2 starts, which makes client #1 fail
>with "invalid service group context id"
>Josef
>  
>
Are you sending service group id in each request , or you juts send as
new req ?
If you want to go into same soapsession , then you need to send the
serviceGroupID


+++> I logged thisi as JIRA AXIS2-1991 - if we share somehow the location 
where the ServiceGroupContextID is taken from or stored, then, when a second 
client calls and Axis2 does not check somehow that a ServiceGroupContextID is
already created, it will override the existing one. I do not know if that
is true, but if the ID gets overridden, then we ghave at least the mentioned 
effect. 

As simple as have an ID it in a static field. This migth be true for a larger 
object modells as well as simple variables ... sharing versus non sharing 
wether this is happen in the same thread or in different threads, 
makes it just more complex. <+++



>>I have read in a dcoument about axis session managment @
>>http://www.developer.com/java/web/print.php/3620661 "that axis2 is
>>meant to be an enterprise web service engine, so it has to support
>>session management."
>>
>>    
>>
>The article is little bit out dated , since we had few changes from
>Axis2 1.0 to 1.1
>
>
>
>So where is a new articel reflecting the same topic?
>What values does this articel have among well undestood generics when
>I can not count on the little code fragments given. Also a previous
>mail has lead me to this articel. So how far is it outdated?
>Josef
>
>  
>
I will update that and publish soon.

Thanks
Deepal



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to