Hey Deepal,

Thanks for the reply and no misunderstandings at all.

I am defintely +1 for the module approach. (As I mentioned to you before)
As long as I can add the config to the axis2 system module approach is great. Well infact module is the best approach.

>And I think adding a method to get session manager from AxisService and AxisConfiguration is not sound good to me , we have some other >alternatives as you know even service implementation class we store as a parameter
Actually currently it gets the Global session manager from AxisConfiguration.
I was thinking about allowing to define a session manager on a per service level, hence the AxisService

for instance you want only certain services to be clustered.

However if there is an alternative way of handling this, then I am happy to do that.
Can u please elaborate on these alternatives. I can quickly change the code to support that.

>I dont know whether I am missing something , can you please explain how do you plan to do clustering with your session management >proposal.
No my mistake on not explaning this. We cluster the sessions using WADI or maybe richochet or JGroups.
The idea is to carry the simple conversation to another node if the primary node fails.

How clustering is done depends on what we use. In side Axis2 we will only have the glue code to wire to the underlying infrastructure.
Currently an effort in WADI is in full swing.

> And adding session management related stuff into Message receivers not going to be work , since ppl can write their own message receivers, > so in that case he has to aware of session management.
You are absolutely right.
This is totally a hack and temporary messure untill I figure out the propoer solution.

I need help in figuring out how to pass the session object between the inpipeline and the out pipeline. (thats one issue)

the other is for me to figure out a way to capture the start and end of a message processing.
the sync case is good, but the async case is tricky as the real work is happening in the back ground thread and I need to figure out when the processing ends.

I am sure there is a way. Lets brain storm and find a way.

Thanks a lot for the feedback.

Regards,

Rajith


On 6/21/06, Deepal Jayasinghe (JIRA) <[EMAIL PROTECTED]> wrote:
    [ http://issues.apache.org/jira/browse/AXIS2-532?page=comments#action_12417068 ]

Deepal Jayasinghe commented on AXIS2-532:
-----------------------------------------

Hi Rajitha

I wen through your patch + documents and they are great. But I have few concern about the patch and the proposal (please please dont misunderstand me).

From your patch I realized that you are trying to do a number of changes to Axis2 to support session management. As you know we have session management in Axis2 and it has limitation too.  As described in your proposal we can not manage session across services groups , so the ideal solution would be to add a way to change service group at the runtime.

And I really want to rename the servicegroupId   into something else :)

I dont know whether I am missing something , can you please explain how do you plan to do clustering with your session management proposal.

As I suggested sometimes ago  you can implement the proposal as Axis2 module (like Sandesha , Rampart) , since what you want is to add two handles in the flows and share some data across invocations.

Any way from the patch I found following can be change nicely to implement Session management as a module.

You dont need to add two handlers into axis2.xml , what you can do is to add a module.xml and add the handlers there what do you think

  +<handler name="SessionHandler"
+                     class=" org.apache.axis2.session.SessionHandler">
+                <order phase="PreDispatch" phaseLast="true"/>
+            </handler>


<phase name="MessageOut">
+            <handler name="EndOfRequestHandler"
+                     class="org.apache.axis2.session.EndOfRequestHandler">
+                <order phase="MessageOut" phaseFirst="true"/>
+            </handler>
</phase>


Do we need to support by default , so having default session management stuff in axis2.xml is not good to me , what I suggest is to have them as parameters then you dont need to do any modifications to AxisConfigBuilder or any other core axis2 classes. Still I am thinking to implement session management as a module like Sandesha.

+    <!-- ================================================= -->
+    <!-- Session Management and Clustering  -->
+    <!-- Comment this section on client side, no session management is needed for client side -->
+    <!-- ================================================= -->
+    <sessionManagerFactory class="org.apache.axis2.session.DefaultSessionManagerFactory">
+       <sessionManager class=" org.apache.axis2.session.Axis2SessionManager">
Do you really need to have separate field to store session object in Message context , you can store that as a property.

And adding session management related stuff into Message receivers not going to be work , since ppl can write their own message receivers, so in that case he has to aware of session management.

AxisService service = msgContext.getAxisService();
+               if (service !=null && service.getSessionManager() != null){
+                       return service.getSessionManager();
+               }


And I think adding a method to get session manager from AxisService and AxisConfiguration is not sound good to me , we have some other alternatives as you know even service implementation class we store as a parameter

// first check if there is a session manager for the service
+               AxisService service = msgContext.getAxisService();
+               if (service !=null && service.getSessionManager() != null){
+                       return service.getSessionManager();
+               }


So please comment on this and I am very sorry for my delay to reply


> Session Management
> ------------------
>
>          Key: AXIS2-532
>          URL: http://issues.apache.org/jira/browse/AXIS2-532
>      Project: Apache Axis 2.0 (Axis2)
>         Type: New Feature

>     Versions: 0.95
>     Reporter: Rajith Attapattu
>  Attachments: session_march_28.patch, session_mgt_march29.patch, session_mgt_march30.patch, session_mgt_march31.patch
>
> Session Management
> -------------------------------
> This patch containes transport independent session mgt using WS-Addressing EPRs
> Interfaces
> --------------
> All interfaces are located in the core module
> Main interfaces useful for users
> org.apache.axis2.session.Session
> org.apache.axis2.session.SessionManager
> org.apache.axis2.session.SessionIdFactory
> There is a Null impl for these interfaces within core
> Implementation
> ------------------------
> All implementation specific classes are located in the session module
> Clustering impl
> ----------------------
> Clustering impl is located within the clustering module
> (only empty classes so far)
> Examples (located in the samples module)
> -----------------
> ATM example
> sample.session.atm.*
> Echo example
> sample.session.echo.*

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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


Reply via email to