From dev-return-26051-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Wed Mar 01 19:56:05 2006 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 77590 invoked from network); 1 Mar 2006 19:56:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Mar 2006 19:56:03 -0000 Received: (qmail 48558 invoked by uid 500); 1 Mar 2006 19:56:47 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 48505 invoked by uid 500); 1 Mar 2006 19:56:46 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 48494 invoked by uid 99); 1 Mar 2006 19:56:46 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 11:56:46 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [199.237.51.194] (HELO green.rootmode.com) (199.237.51.194) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 11:56:45 -0800 X-ClientAddr: 68.171.62.46 Received: from [192.168.15.100] (68-171-62-46.vnnyca.adelphia.net [68.171.62.46]) by green.rootmode.com (8.12.10/8.12.10) with ESMTP id k21JuJtw012073 for ; Wed, 1 Mar 2006 14:56:19 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com> <44042DE9.2080203@mortbay.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9917E786-6125-4DB9-BBEF-E2AFDECCB615@iq80.com> Content-Transfer-Encoding: 7bit From: Dain Sundstrom Subject: Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany Date: Wed, 1 Mar 2006 11:56:22 -0800 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.746.2) X-RootMode-MailScanner-Information: Please contact the ISP for more information X-RootMode-MailScanner: Found to be clean X-MailScanner-From: dain@iq80.com X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Actually, the more I think about it, you are bringing up the need for another API for request routing. This would be something that can make a decision about what to do with a request and could optionally work with out session API. I'm thinking of something that captures the concept of a request and a decision. Off the top of my head... public interface Request { Object getHeader(); String getSessionId(); String getTarget(); } public interface Router { public RouterPolicy route(Request request); } RouterPolicy is an enumeration containing local, move session, proxy, redirect. With a simple API like this we should be able to enable smart load balancing features contained in the clustering implementations out there today, while keeping the caller's job simple. -dain On Mar 1, 2006, at 11:32 AM, Dain Sundstrom wrote: > Wow, this is a lot to digest. I'll attempt, but we may want to > deal with these one by one... > > On Feb 28, 2006, at 3:03 AM, Greg Wilkins wrote: > >> >> Responding to this a bit late.... >> >> >> I like the concept of a Session API that can hide >> all the variations of session implementations from the web container. >> Instead of having different session managers for the different >> clustering mechanisms, I'd like to have one session manager >> written to this API that receives a Locator implementation and >> everything else is hidden from it. >> >> This API looks like a good start, but I think it is missing lots >> that I'll need to write a jetty session manager that is based on >> it: >> >> >> ID Management >> ============= >> Firstly, the API represents a flat session ID space and >> I'm not sure that is sufficient. With cross context >> dispatch you may have several different web sessions that >> share the same ID. Also, EJB sessions may share that >> ID and may be at different locations to the web session. > > The idea was to build the simplest API that could preform. We > tried to leave complex session constructs out of the API. James > and I did talk about some of this stuff and thought we could simply > build a complex string to lookup the session data in the flat map. > >> So I think the API needs some more capabilities for >> session ID management. Specifically the following questions >> needs to be asked and answered: >> >> + Does session ID x exist in the whole server/cluster) > > You always know every session that exists in the cluster: > > locator.getSessionLocation(x) > >> + Does session ID x exist for context y > > In this case, I would say you lookup the session "x" and then see > if it has an entry for context "y" > >> + get WEB session with ID x for context y > > No idea what that means > >> + invalidate ALL sessions with ID x > > SessionLocation.destroy() > >> + passivate ALL sessions (suspending node) > > That would happen under the covers of the session API (i.e., > implementation specific) > >> + invalidate ALL sessions (shutting down) > > Implementation specific > >> Now the above could be modelled with deep structure for the >> state associated with an ID, but not if all state for an ID >> has to be in one location. > > Having all of the state for a single session located on a single > machine is a design assumption. We felt that if you wanted to let > the data be divided across several machines it was not a single > session session. > >> Session Management >> ================== >> There is nothing in the API to help with session management. >> Specifically: >> >> + last access time >> + access session (without actually modify state) >> + invalidate session >> + session timeouts >> + session events (eg session invalidation, passivation etc.) > > Other than last access time, I would classify this as > implementation specific. The goal was to create a very very simply > API that OpenEJB, ServiceMix, Lingo, Tuscany and web containers > could use without haveing to know the internal details of the > implementation. Does you code specifically need this or it is a > nice to have? If it is the former, can you be a lot more specic on > what the terms above mean (I'm not a web expert) :) > >> Locking >> ======= >> I'm also not sure about the semantics of release(). If I'm >> writing a session manager, I'm not sure if I should be making >> the decision of when to release - that is very much implementation >> dependent. Some will replicate/sync on a setState, others will >> do it at the end of every request, other will do it every n seconds >> others will do it when the session is idle (has no requests). >> >> Instead of commanding "release", perhaps the API should allow >> the concept of a thread entering and existing a session scope: >> >> runInSessionScope(Runnable doSomething >> >> or >> >> enterSessionScope() >> leaveSessionScope() >> >> individual implementations can decide what locking they >> implement behind the scenes. > > That is exactly how the API works. When you start using a session > you need to acquire it using the Locator and when you are done > using it, you release it. This is reference counting, and when the > count reaches zero we are in a stable state and can replicate. > Here is a test case that shows normal usage: > > http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/ > test/org/apache/geronimo/session/SessionTest.java > >> Policy >> ====== >> >> The SessionLocation interface has the start of a policy >> API for managing session location. Cool, but I don't >> want the web SessionManager to have to implement policy. >> I don't want to have to call moveLocally() - I want something >> else to have called that before the request comes near >> the web containers session manager. >> >> So I think the API needs to have the concept of a Policy >> implementation that can be invoked before and after a >> session is accessed. > > I'm not sure exactly what you are looking for, but the following > test case shows the usage of move, redirect or proxy policies. > > http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/ > test/org/apache/geronimo/session/remote/RemoteSessionTest.java > > We could add an API for making this decision, but I think the > decision policy is very specific to the client. For example, in > EJB you normally have a smart client, so the default policy is > should be clien side redirect. > >> Meta Data >> ========= >> >> To implement a policy, we are going to need to implement >> some meta data channelling. For example, if we are running >> in the scenario where requests can be proxied to where a >> session lives - we might want to have a policy that if >> a session sees lots of requests being proxied from a >> specific node (load balancer changed?) then that session >> might want to move itself to that node. > > Assuming we do add an interface to make the decision, I would hope > that all of these details would be implementation specific (i.e., > under the covers of a very simple interface). > >> So firstly we need SessionLocatoin.moveto(Server server), > > I'm confused. Why would we need that? > >> but more importantly, when we are redirecting or proxying >> requests, it would be good to be able to attach impl >> specific meta data to those requests. So the HTTP tier >> needs to be able to ask a SessionLocation for an opaque >> blob of meta data associated with a request and to be >> able to set that meta data when it recieves it. > > Huh? Redirect would be dependent on the web container so this > would be a detail for the web container to deal with. The session > apis, only says, "the session data is on server x". How the web > container gets the request to server x is it's problem. > >> I guess the nodes could communicate that meta data via >> out-of-band paths, but then you are in a world of synchronization >> pain - specially if the cluster grows, shrinks or changes. > > I'm really confused now. I don't know why you would need any kind > of out-of-band meta data. The session apis are designed around the > concept of movable locks. In a moveable lock system, you only need > to know where the lock is located. If it is on your local machine > you just grab the lock. If it is remote, you can either move the > lock to the lock request, or move the lock request to the lock. > There should be no need for extra metadata, and the system should > scale very well. > >> Anyway, very soon, I'd like to start on the jetty6 geronimo >> modules. So perhaps a way to turn these negative comments into > > I didn't take these negatively at all. You are stating to look at > these from a user's perspective and there will always be confusion, > missing features and problems in new APIs. > >> positive suggestions is if I try to use the jetty6 module to >> implement a session manager based on this API and then make changes >> to make it work. > > I would prefer that we discuss the API changes first. There are > many uses for this API and I want to keep them simple and avoid > making them to servlet centric. I think if we carefully work out > the APIs we can have something that works well for all of the users > (i.e., OpenEJB, ServiceMix, Lingo, Tuscany and web containers) and > the implementers (i.e., WADI, ehCache, java.util.HashMap, TangoSol, > ObjectGrid). > > -dain