On Sun, Aug 23, 2009 at 4:50 AM, Kevin Wright <[email protected] > wrote:
> I'm wondering if we can't leverage JavaSpaces to handle a lot of this > stuff. From my experience with the technology it seems to be a pretty good > fit for the problem. Two reasons: - JavaSpaces is as far as I know, GPL and we will not mix any GPL into Lift - It doesn't solve the issue with low-level session replication which relies on serialization of the session data for transfer to another app server instance. > > > > On Sun, Aug 23, 2009 at 11:06 AM, marius d. <[email protected]>wrote: > >> >> Changed the thread subject ... >> >> Marius >> >> On Aug 22, 6:17 pm, "marius d." <[email protected]> wrote: >> > Great thing Dave. >> > >> > Roughly having a bound function f that user provided say in an >> > ajaxButton call.The function f may hold references to other functions, >> > session/request-vars, references to the snippets instances etc. One >> > condition is that every object in the graph should be serializable and >> > that is beyond our control (but more on the programmer's control). Of >> > course for the function f to be correctly applied on any node, the >> > whole object graph should be replicated among cluster nodes). >> > >> > Now assuming that we can serialize any function/object on the wire >> > there is still one thing to solve. As you know LiftSession and >> > HTTPSession are not the same things. a LiftSession is linked to a >> > HTTPSession so we'd probably need to replicate both? Systems like stax >> > have their own way to make a HTTPSession available to any cluster node >> > AFAIK by saving it into a database. Into such environments I'm not >> > such if we know the actual machines identity andif we would have built >> > our own replication system in a clustered env. that would probably not >> > work ... so a node to node replication system may not be possible in >> > stax like environments but would certainly work on other models. Still >> > persisting a LiftSession in DB shoud and sounds like it is more >> > environment agnostic. >> > >> > In a glance node-to-node session replication sounds to be a little >> > more efficient that DB session store we should probably keep an eye >> > on both models. Other model that could be to lazily replicate sessions >> > across cluster nodes such as: >> > >> > 1. Upon a request Node A advertises to other nodes that it hods the >> > last state for session X >> > 2. Upon a subsequent call that hits node B it won;t have the session >> > but it would know where the session exist a fetch the state from that >> > node >> > 3. Node Node B advertises that it has the last state for session X >> > >> > ... Such model is not very fail over proof as at a given point in time >> > different versions of the session state which may or may not enough. >> > >> > The most consistent model seems to be to store the session context >> > into a centralized session store ... but that would induce a single >> > point of failure unless the session store itself is redundant. >> > >> > Last but not the least Java serialization is sub-optimal but I'm not >> > sure how many alternatives we'd have in order to make sure that we >> > have a consistent reference graph that can be represented on the >> > wire.. >> > >> > Br's, >> > Marius >> > >> > On Aug 22, 5:25 pm, David Pollak <[email protected]> >> > wrote: >> > >> > > On Sat, Aug 22, 2009 at 2:31 AM, marius d. <[email protected]> >> wrote: >> > >> > > > Greg/Viktor, >> > >> > > > We could meet and discuss using whatever means (skype, chat, mail >> > > > etc.) and brainstorm what can we do about this. Even though I like a >> > > > lot sticky sessions idiom it is not enough and I think we do have a >> > > > consensus here :) ... of course any committer is more then welcome >> to >> > > > participate. >> > >> > > On the substance point (I've moved this to the Lift list), we may want >> to >> > > use some aspecty thing to analyze the potential serializability of >> functions >> > > that are added to the LiftSession. I'm betting there's no actual >> barrier to >> > > serializing stuff in the normal case except when things refer to the >> > > HttpServletRequest (which refers to input/output streams). If we >> could get >> > > an actual analysis, we could develop a better serialization/session >> moving >> > > strategy. >> > >> > > > Br's, >> > > > Marius >> > >> > > > On Aug 22, 12:15 am, Viktor Klang wrote: >> > > > > On Fri, Aug 21, 2009 at 11:12 PM, Meredith Gregory >> > >> > > > > > wrote: >> > > > > > Marius, >> > >> > > > i really do want to go over lift's ability to >> > > > > > work in vendor supplied clustering solutions. >> > >> > > > > We could do a Skype conf when you're feeling better, Greg. >> > >> > > -- >> > > Lift, the simply functional web frameworkhttp://liftweb.net >> > > Beginning Scalahttp://www.apress.com/book/view/1430219890 >> > > Follow me:http://twitter.com/dpp >> > > Git some:http://github.com/dpp >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
