I've been playing with JINI a few years ago a liked it a lot (not a simple programming model, but JavaSpace reduces a lot of such complexity) but I'm not sure how fitful it really is in stax like environments where broadcast UDP may not be supported so discovery service would be more difficult.
Br's, Marius On Aug 23, 2:50 pm, 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. > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
