Hi all
 
It seams that no-one of the axis2 developers, mainly the one introducing 
scope="soapsession" are able
to deliver me an answer to my questions below. a while ago, two years ago in 
fact I run still axis2-1.2 on
OpenVMS, I was 100% confident that I have a thread/session safe configuration 
when I run in 
 
scope="soapsession"; mode
 
however this is only true for java axis2 based service clients; this is the 
out-come of the past months!
 
The various stories say - that one has to return the ServicegroupId's with each 
request, in a soap-header.
 
OK I beleaved this. And I garantee you, all my wcf clients do it.
 
Meanwhile, I am 100% confident, as I am currently struggle arroun to make Vista 
clients using .NET,
C#, WCF work toward an axis2 server running in scope="soapsession"; 
 
THAT THIS IS SIMPLY NOT TRUE!
 
what I learned and have detected so far using tcpmon is
 
Every axis2 java service client accepts cookies and hence the server returns on 
its initial request
(when the sessiion is new) a 
 
Set-Cookie; JSESSIONID=< id > ; Path=/axis2
 
This as a web http header in its reply when a first request is made, which 
calls init() and then my own login() 
(when the session is new:)
 
and with this first response, as said in documentation;  I get the awaited 
ServiceGroupId back.
 
This ServicegroupId is said to be the identifier one has to return with each 
follow-request to the
server to reach the same instance of a service, to talk to the same object; to 
have in fact sessions
/threads implemented; however - that is not true - without the coockie it does 
not work.
 
The quite reader might have assumed that I run via HttpTransport not via 
TcpTransports; We do so.
 
Now; I have 3 Java axis2 service clients running; and each is reaching its own 
object/service, each sends
its own garanteed unique JSESSIONID at the http-request-header-level and its 
own garanteed unique 
ServiceGroupId at the soap-request-header-level
 
And it works;
 
I start my first wcf client and well it works; 
This wcf client sends garanteed unique its JSESSION and its garanteed unique 
ServicveGroupId
with each request; see below; we have init() login() fktmap() fktmap() fktmap() 
init() login() ...
and please take notice the when the ServiceContext ID changes;
 
And it works;
 
I start my second wcf client an well it receives with its initial request (it 
calls init() ( it's garanteed unique JSESSIONID and its 
garanteed unique ServicegroupId; 
 
But when I look at my log in  
AXP1>ty APACHE$SPECIFIC:[000000]APACHE$JAKARTA_SERVER_OUTPUT.LOG/out=x.x
 
I can find the following sequence of calls; and as you can see, when my third 
vista wcf client starts destroy() gets called twice for my
two previous still in use ServiceContext, and that is the deadly end of the 
unique services serving wcf client 1 and 2

AXP1>search x.x "-  init()","-  login()","-  fktmap","-  logout()","-  
destroy()"
-  init()    called at : Wed Mar 18 08:38:40 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=0
-  login()   called at : Wed Mar 18 08:38:40 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=1 and session is NEW
-  fktmap()  called at : Wed Mar 18 08:38:48 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=2
-  fktmap()  called at : Wed Mar 18 08:38:50 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=3
-  fktmap()  called at : Wed Mar 18 08:38:57 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=4
-  init()    called at : Wed Mar 18 08:39:24 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=0
-  login()   called at : Wed Mar 18 08:39:24 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=1 and session is NEW
-  fktmap()  called at : Wed Mar 18 08:39:32 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=2
-  fktmap()  called at : Wed Mar 18 08:39:35 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=3
-  fktmap()  called at : Wed Mar 18 08:39:41 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=4
-  destroy() called at : Wed Mar 18 08:41:05 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe418d28> 
org.apache.axis2.context.servicecont...@fe418d28 i=5
-  destroy() called at : Wed Mar 18 08:41:05 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3c1573> 
org.apache.axis2.context.servicecont...@fe3c1573 i=5
-  init()    called at : Wed Mar 18 08:41:05 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3a6bc4> 
org.apache.axis2.context.servicecont...@fe3a6bc4 i=0
-  login()   called at : Wed Mar 18 08:41:05 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3a6bc4> 
org.apache.axis2.context.servicecont...@fe3a6bc4 i=1 and session is NEW
-  fktmap()  called at : Wed Mar 18 08:41:14 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3a6bc4> 
org.apache.axis2.context.servicecont...@fe3a6bc4 i=2
-  fktmap()  called at : Wed Mar 18 08:41:16 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3a6bc4> 
org.apache.axis2.context.servicecont...@fe3a6bc4 i=3
-  fktmap()  called at : Wed Mar 18 08:41:23 MET 2009 using  
<mailto:org.apache.axis2.context.servicecont...@fe3a6bc4> 
org.apache.axis2.context.servicecont...@fe3a6bc4 i=4
AXP1>ty APACHE$SPECIFIC:[000000]APACHE$JAKARTA_SERVER_OUTPUT.LOG/out=x.x

 
 
My question is still: what makes axis2 server calling destroy() twice in this 
condition?
 
As nobody from the axis2 developers community seems to be able to tell me the 
circumstances under which "destroy()" gets called
that forces me to do something I did 2 years ago; I have to debug axis2 server 
engine / disptachers and try to find myself the 
answer and the conditions responsible to send me to destroy(); I did it two 
years agoe and I had to draw 18 A3 sheets of
UML sequence-diagrams until I could see how a request is delivered to then 
service instance. Well, I have to do it again now.
 
Thank you very much for your attention.
 
Josef.Stadelmann
@axa-winterthur.ch
 

-----Ursprüngliche Nachricht-----
Von: Stadelmann Josef [mailto:[email protected]]
Gesendet: Donnerstag, 12. März 2009 18:48
An: axis-user (E-Mail)
Betreff: scope="soapsession" what causes destroy() to be called



Hi,

my web service runs in scope="soapsession"

up on a client request, call it session 1, the following functions are called 
in sequence for my login cycle

init(), login(), fktmap(), fktmap(), fktmap(),


then I start the next client, calle it session 2) and the following functions 
should becalled

init(), login(), fktmap(), fktmap(), fktmap(),

but the following functions are called in sequence

destroy(), init(), login(), fktmap(), fktmap(), fktmap(),

in bold the axis2 requierd functions one needs to implement for 
scope="soapsession"

destroy() is the bad guy which deletes me the previous created instance;

hence thereafter client 1 / session 1 is inoperable and returns a fault to the 
client telling me that ServicegroupId is invalid

but that is not true, as TcpMonitor proves the opposit for every more session 1 
calls to fktmap()

Question:

under which conditions, httpMessageRequestHeader issue, http protocol 
dependent, is destroy() called?

Note: with the primary call action="urn:login" the server responses with a 
setCooky and passes me the cooky=JSnnnnn...

what httpRequestMessageHeader must be there or absent that a first request from 
a new session does not call destry()


Only then will consecutive requests with the same ServiceGroupId in fact reach 
the old service instance to which it belongs;

So a request with action="urn:login" shall hit init(), then login(), in absence 
of a ServicegroupId, but at no time destroy()

Josef



Reply via email to