I guess JGroups is another alternative here, it's a bit lower level, but does let you set up nodes manually - so it's not an issue that you need UDP broadcast (although it helps...)
On Sun, Aug 23, 2009 at 1:09 PM, marius d. <marius.dan...@gmail.com> wrote: > > 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 <kev.lee.wri...@googlemail.com> > 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. <marius.dan...@gmail.com> > wrote: > > > > > Changed the thread subject ... > > > > > Marius > > > > > On Aug 22, 6:17 pm, "marius d." <marius.dan...@gmail.com> 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 <feeder.of.the.be...@gmail.com> > > > > wrote: > > > > > > > On Sat, Aug 22, 2009 at 2:31 AM, marius d. < > marius.dan...@gmail.com> > > > 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
