Hi Deepal
pls see my coment below
-----Ursprüngliche Nachricht-----
Von: Deepal Jayasinghe [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 29. November 2006 17:27
An: [email protected]
Betreff: Re: sesion managment, scope=soapsession
Hi Stadelmann ;
pls see my comments below;
> Hi session-managers,
>
>
> I'm running my client and server with modules addressing-1.1, logging,
> soapmonitor-1.1 engaged and have set scope=soapsession
>
> MyService.java got the additional methods
>
> public void init(ServiceContext sCtx) {
> this.sc = sCtx;
> this.log.info(sc.toString()+" init() called ");
> }
>
> public void destroy(ServiceContext sCtx) {
> if(!this.sc.toString().equals(sCtx.toString())){
> this.log.error("ServiceContext on init() and destroy() not
> equal in ");
> }
> this.log.info(sc.toString()+" destroy() called ");
> }
>
> public void setOperationContext(OperationContext oCtx) {
> this.oc = oCtx;
> this.log.info(oc.toString()+" setOperationContext() called
> ");
> }
>
We have removed this method (it was there in Axis2 1.0 , but we removed
that from Axis2 1.1), so we are no longer going to call this method . If
you want to get access to operation context , then you can do that as
follows;
MessageContext msgCtx = MessageContext.getCurrentContext();
from msgCtx you can access any of the contexts you want .
OK - i take this into consideration
>
>
> I start client #1 which has the effect that MyService.init() is
> called; so far so right!
> Client #1 then loops and sends continously messages to MyService.echo()
> I start client #2 which has the effect that MyService.destroy() is
> called followed by MyService.init()
> This has the effect that client #1 fails with an "invalid group
> context id exception"
>
> Is this a bug?
>
Nope. That is not a bug , soapsession has concept of time out , so once
it gets time out you will get that exception.
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"
>
>
> I have studied the architecture of axis2 and have drilled down in code
> and I came down to where alle the service objects are finally called
> at "invokeBusinessLogic" (inCtx, outCtx) with it's call to
> "method.invoke" ( . . . )
>
good .
> All reading in code and documentation did not answer my questions ***
> How does Axis2 manage / support long-lasting-sessions to
> server-objects bound to this session ? ***
>
> Do I have to implement this myself on top of Axis2?
>
No , you can get support from Axis2 session management. If you have
Axis2 1.1 distribution there you can find a sample called Library sample
, which help you to understand most of the important factors.
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?
>
> 1. I want to have a client-object exchanging OMElements with it's
> service-class-object.
>
yes , doable
> 2. when the client starts the session, up on receiving the first
> message, a unique instance of the service-class-object shall be
> created at the server.
>
yes , that is what happen.
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.
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
> 2a) 20 client objects shall mean we have instantiated 20
> dedicated-server-objects
>
yes.
> 3. as long as this 20 service-class-object exists, in fact 20
> wrapper-object to 20 external server process, and as long as this 20
> external process exist it shall not be allowed that one single
> service-class-object dies. for that reasioon the server-objects must
> exist until it's dedicated client terminates the session esplicitly by
> calling logout() on the server-object.
>
Nope , the behavior of soapsession is not like that. It has a notion of
time out. If the user does not touch the service for about 30s (time
interval is configurable) , then the session will be automatically
terminated.
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
> 4. every message sent by a client has to reach exact the same instance
> of the service-class-object as the previous message did, anything else
> would be considerd a security risk, a fault, an error.
>
yes , we are mapping to the same session using special header parameter
called "ServiceGroupID"
That does not work in my mind, at least it can not be used to keep separate
sessions. Why is the "service group context id" re-created by the second client
making the first running client fail?
Josef
>
>
> 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 have read all related e-mails and implemented soap-sessions which
> work nicely with one client and one server. But they die when the
> second client starts as descibed above. the second client creates a
> new service-group-id when and the old one gets lost. THis happens in
> my mind because destry is called implicit. So client-1 then fails as
> it's known service-group-id does no longer exist.
>
>
>
> I have not found in all the e-mail of the past 3 months a clear idea
> or an answer to this often asked questions about "how to implement
> sessions to such server side obejcts".
>
> I must admit, I do not understand how ws-addressing supports my demand.
>
> Can I managment my sessions with axis2 in an elegant way or do I have
> to fall-back to servlets and tomcat?
>
> I would really appreciate any answers and thank you very much to
> answer my burning question not only for my own satisfaction. Thank you.
>
> Josef
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
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]
