Return-Path: Delivered-To: apmail-axis-java-user-archive@www.apache.org Received: (qmail 1130 invoked from network); 26 Jan 2011 09:45:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Jan 2011 09:45:30 -0000 Received: (qmail 4919 invoked by uid 500); 26 Jan 2011 09:45:28 -0000 Delivered-To: apmail-axis-java-user-archive@axis.apache.org Received: (qmail 4555 invoked by uid 500); 26 Jan 2011 09:45:25 -0000 Mailing-List: contact java-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@axis.apache.org Delivered-To: mailing list java-user@axis.apache.org Received: (qmail 4547 invoked by uid 99); 26 Jan 2011 09:45:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jan 2011 09:45:24 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [194.40.127.75] (HELO C005894.axa.ch) (194.40.127.75) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jan 2011 09:45:15 +0000 X-IronPort-AV: E=Sophos;i="4.60,379,1291590000"; d="scan'208,217";a="27626044" Received: from c005811.chres1.doleni.net ([194.40.60.11]) by C005894.ch.winterthur.com with ESMTP; 26 Jan 2011 10:37:40 +0100 Received: from c005815.chres1.doleni.net ([194.40.60.9]) by c005811.chres1.doleni.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 10:44:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBD3D.AF2170C3" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: axis2 session scopes Date: Wed, 26 Jan 2011 10:44:53 +0100 Message-ID: In-Reply-To: <419625.53014.qm@web45505.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: axis2 session scopes Thread-Index: Acu75nGC494AlI5cSEK9UQ7GxNI9fgBVVyVw References: <485946.67008.qm@web45511.mail.sp1.yahoo.com> <193706.24643.qm@web45502.mail.sp1.yahoo.com> <4D3C3644.1020402@opensource.lk> <90861.54440.qm@web45512.mail.sp1.yahoo.com> <4D3C8ECE.1030106@gmail.com> <64976.62042.qm@web45504.mail.sp1.yahoo.com> <4D3C94E7.6090402@gmail.com> <419625.53014.qm@web45505.mail.sp1.yahoo.com> From: "Stadelmann Josef" To: X-OriginalArrivalTime: 26 Jan 2011 09:44:54.0027 (UTC) FILETIME=[AF340DB0:01CBBD3D] X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01CBBD3D.AF2170C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We use scope=3D"soapsession" in the following case =20 A: we have 3 different client programs running from the same PC each with the same WS stub.=20 =20 B: Each one of the 3 client shall span one dedicated user session thread to a dedicated web service based object, which is an instance of your web service class. (Think how a client-object finds its server-object via a strong link) cA talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or sC. Just a 1 to 1 object relation. =20 B: By using scope=3D"soapsession" the initial call of cA to the web service creates for our service class a web service object sA (as instance) and it returns a servicegroupId Header to the calling client cA. =20 C: The client cA is now required to send his received servicegroupId in the addressing header with each request to the axis2 engine which dispatches the request to sA =20 D: that way we can guarantee you that each users client session thread i.e. cA, reaches always the same service object (instance) sA =20 E: and by adjusting a timeout in the client and the server we have long lasting objects, client and server side, objects talking to each other for hours. And we have no need to re-establish for each request a new stub or a new service providing object. =20 =20 Josef =20 Von: am am [mailto:akmeref@yahoo.com]=20 Gesendet: Montag, 24. Januar 2011 17:47 An: java-user@axis.apache.org Betreff: Re: axis2 session scopes =20 Ah, I see now. So the idea is that either a single instance of a serviceClient is reused across calls or if new instances must be used it must be directed to the specific serviceGroupId. Right? For soapSession scope as mentioned in the article we use the=20 client.getServiceContext().getTargetEPR().getAllReferenceParameters().ge t(new QName("http://ws.apache.org/namespaces/axis2","ServiceGroupId ")); for transportSession what is the approach? The above method returns null (since there is no replyto header I guess) but on transport which is based on cookies, I set to client the managesession attribute to true, and still can not re-use session across different service clients objects. What is the approach on transport? Thank you! =20 ________________________________ From: Deepal jayasinghe To: java-user@axis.apache.org Sent: Sun, January 23, 2011 10:51:51 PM Subject: Re: axis2 session scopes The problem is not sending the servicegroupID or the session related information. When you keep sending request it always create a new instances, only way to stop is to copy the servicegroupID from the previous request and send it alone with the next request. One another way to get this work is try following, then you will see the expected behavior. ServiceClient client =3D new ServiceClient(); Options options =3D new Options(); options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi ce")); options.setManageSession(true); client.setOptions(opts); client.invokeBlocking(); client.invokeBlocking(); client.invokeBlocking(); If we do the above, you only get one service instances. Deepal The article describes how to keep session, without needing to reuse the same ServiceClient object. I.e. keep session using different ServiceClient objects. My question was, why is the web service class being re-instantiated for each web service invocation for ALL scopes except application. I have configured client to manage session (and engaged addressing for soapsession) and the web service class keeps-on re-instantiated for each web service call. So, I am not having a problem on keeping/using session (I am using messageContext and serviceContext for session related data). I can not understand why the web service class is re-instantiated. Is this a bug in Axis2? If not, what is the logic for this? I think that for enterprise level application this is too costly. Is some sample code needed for this? Thank you =20 =20 ________________________________ From: Deepal jayasinghe =20 To: java-user@axis.apache.org Sent: Sun, January 23, 2011 10:25:50 PM Subject: Re: axis2 session scopes Now, I got the point. For that you need to try the following. http://wso2.org/library/3184 Deepal Hi Deepal, I have tried all scopes. In client side I have set manage session to true. For instance. I set the session scope in services.xml to "transportsession". In the web service I use=20 MessageContext messageContext =3D MessageContext.getCurrentMessageContext(); ServiceContext scontext =3D messageContext.getServiceContext(); To store values to last per session. e.g.=20 scontext.setProperty("SUM","" + sum); and I re-use sum across invocations.=20 Also in client I do: ServiceClient client =3D new ServiceClient(); Options options =3D new Options(); options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi ce")); options.setManageSession(true); client.setOptions(opts); I can see that the data I place in MessageContext persist across invocations but I also see that a new web service instance is created per invocation. =20 So my question is, that the session data will persist but I should expect the web service to be re-instantiated per invocation? =20 In the example of transport session I have in the web service: public class MyLittleWebService{ =20 publicMyLittleWebService(){ System.out.println("MyLittleService constructor called! New Instance created!"); } And the constructor is being called across all invocations for all types of session except application. =20 So I understand I must use session data, but this is the expected behavior as well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise level web services? If I am confused on this, please help me out understand what am I doing wrong here. Thank you =20 ________________________________ From: Deepal Jayasinghe =20 To: java-user@axis.apache.org Sent: Sun, January 23, 2011 4:08:04 PM Subject: Re: axis2 session scopes On 1/23/2011 7:11 AM, am am wrote:=20 I am starting on axis2 (1.5.4). I am looking into the various session scopes for web services (request, soapsession etc). By experimenting, I notice that in all scopes except the application scope, there is a new instance of my web service being created per service call. Only by setting the scope to "application" in the services.xml, the web service is instantiated only once, and being re-used across all web service calls. My testing for this, was actually a print statement in the web service constructor. The constructor was called for scope=3D"request" or scope=3D"soapsession" or scope=3D"transportsession" for each ws call. So my question is the following: Is this the case in axis2? And if yes, for non-trivial web services, isn't it very costly (to re-instantiate per service call)? Is the recommended approach to use application scope services? Or my understanding is wrong here? Nope, this is not the way Axis2 does the session. As I can see you have not send session related information to manage the session. For example, when you use soapsession you need to send the session ID, which you can do simply by engaging addressing module to both client and server side and setting the setManageSession(true) in the option object. Similarly, when you use transport session you are required to send the cookies, which can also done by setting the above property. For the request session, it creates service instance for each invocation.=20 Deepal Thank you! =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CBBD3D.AF2170C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We use scope=3D"soapsession" in the following = case

 

A: we have 3 different client programs running from the same PC each = with the same WS stub.

 

B: Each one of the 3 client shall span one dedicated user session = thread to a dedicated web service based object, which is an instance of = your web service class.

(Think how a client-object finds its server-object via a strong link) = cA talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB = or sC. Just a 1 to 1 object relation.

 

B: By using scope=3D"soapsession" the initial call of cA to = the web service creates for our service class a web service object sA = (as instance) and it returns a servicegroupId Header to the calling = client cA.

 

C: The client cA is now required to send his received servicegroupId = in the addressing header with each request to the axis2 engine which = dispatches the request to sA

 

D: that way we can guarantee you that each users client session = thread i.e. cA, reaches always the same service object (instance) = sA

 

E: and by adjusting a timeout in the client and the server we have = long lasting objects, client and server side, objects talking to each = other for hours. And we have no need to re-establish for each request a = new stub or a new service providing object.

 

 

Josef

 

Von:<= /b> am am = [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 = 17:47
An: java-user@axis.apache.org
Betreff: Re: = axis2 session scopes

 

Ah, I see now.
So the = idea is that either a single instance of a serviceClient is reused = across calls or if new instances must be used it must be directed to the = specific serviceGroupId. Right?
For soapSession scope as mentioned in = the article we use the 

client.getServiceContext().getTargetEPR().getAllReferenceParameters=
().get(new QName("http://ws.apache.org/namespaces/axis2","Servi=
ceGroupId"));

for transportSession what = is the approach? The above method returns null (since there is no = replyto header I guess) but on transport which is based on cookies, I = set to client the managesession attribute to true, and still can not = re-use session across different service clients objects. What is the = approach on transport?

Thank you!

 

From:= = Deepal jayasinghe <deepalk@gmail.com>
To: = java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 = PM
Subject: Re: axis2 session scopes

The problem = is not sending the servicegroupID or the session related information. = When you keep sending request it always create a new instances, only way = to stop is to copy the servicegroupID from the previous request and send = it alone with the next request.

One another way to get this work = is try following, then you will see the expected = behavior.

ServiceClient client =3D new = ServiceClient();
Options options =3D new = Options();
options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService= "));
options.setManageSession(true);
client.setOptions(opt= s);
client.invokeBlocking();
client.invokeBlocking();
client.inv= okeBlocking();

If we do the above, you only get one service = instances.

Deepal


The article describes how to keep session, without = needing to reuse the same ServiceClient object. I.e. keep session using = different ServiceClient objects.
My question was, why is the web = service class being re-instantiated for each web service invocation for = ALL scopes except application.
I have configured client to manage = session (and engaged addressing for soapsession) and the web service = class keeps-on re-instantiated for each web service call. So, I = am not having a problem on keeping/using session (I am using = messageContext and serviceContext for session related data).
I can = not understand why the web service class is re-instantiated.
Is this = a bug in Axis2? If not, what is the logic for this? I think that for = enterprise level application this is too costly.
Is some sample code = needed for this?

Thank you

 

 

From:= = Deepal jayasinghe <deepalk@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, = January 23, 2011 10:25:50 PM
Subject: Re: axis2 session = scopes

Now, I got the point. For that you need to try the = following.

http://wso2.org/library/3184

Deepal

<= o:p>

Hi Deepal,

I have tried all scopes. = In client side I have set manage session to true.
For instance. I set = the session scope in services.xml to "transportsession".
In = the web service I use
MessageContext messageContext =3D = MessageContext.getCurrentMessageContext();
ServiceContext scontext = =3D messageContext.getServiceContext();
To store values to last per = session. e.g.
scontext.setProperty("SUM","" + = sum); and I re-use sum across invocations.
Also in client I = do:
ServiceClient client =3D new ServiceClient();
Options options = =3D new Options();
options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService= "));
options.setManageSession(true);
client.setOptions(opt= s);
I can see that the data I place in MessageContext persist across = invocations but I also see that a new web service instance is created = per invocation. 
So my question is, that the session data will = persist but I should expect the web service to be re-instantiated per = invocation? 
In the example of transport session I have in the = web service:
public class MyLittleWebService{
    =
    publicMyLittleWebService(){
    =     System.out.println("MyLittleService constructor = called! New Instance created!");
    }

And = the constructor is being called across all invocations for all types of = session except application. 
So I understand I must use session = data, but this is the expected behavior as well? Re-instantiate the WS = per invocation? Isn't it expensive for enterprise level web = services?
If I am confused on this, please help me out understand = what am I doing wrong here.

Thank you

 

From:= = Deepal Jayasinghe <deepal@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, = January 23, 2011 4:08:04 PM
Subject: Re: axis2 session = scopes



On 1/23/2011 7:11 AM, am am wrote: =

I = am starting on axis2 (1.5.4).
I am looking into the various session = scopes for web services (request, soapsession etc).
By experimenting, = I notice that in all scopes except the application scope, there is a new = instance of my web service being created per service call.
Only by = setting the scope to "application" in the services.xml, the = web service is instantiated only once, and being re-used across all web = service calls.
My testing for this, was actually a print statement in = the web service constructor. The constructor was called for = scope=3D"request" or scope=3D"soapsession" or = scope=3D"transportsession" for each ws call.
So my question = is the following: Is this the case in axis2? And if yes, for non-trivial = web services, isn't it very costly (to re-instantiate per service = call)?
Is the recommended approach to use application scope services? = Or my understanding is wrong here?

Nope, this is not the way = Axis2 does the session. As I can see you have not send session related = information to manage the session. For example, when you use soapsession = you need to send the session ID, which you can  do simply by = engaging addressing module to both client and server side and setting = the setManageSession(true) in the option object. Similarly, when you use = transport session you are required to send the cookies, which can also = done by setting the above property. For the request session, it creates = service instance for each invocation. =

Deepal


Thank you!


 

 

 

 

 

 

------_=_NextPart_001_01CBBD3D.AF2170C3--