Cool, thanks, this pretty much solves the question =) On Jul 10, 12:54 am, "marius d." <[email protected]> wrote: > On Jul 10, 10:40 am, DFectuoso <[email protected]> wrote: > > > Thanks, that was very useful, to enable sticky variables i would do > > something like (explain > > herehttp://wiki.stax.net/w/index.php/Application_Clustering > > ) that? > > > So bottom line? An actor can send a message an actor that is living in > > another JVM using sticky variables(or anything else) (sorry i don't > > know if that terracota, don't know what that is) > > An actor can send messages to an actor in the same jvm (or better yet > part of the same class loader's delegation). With Scala's RemoteActors > (http://www.scala-lang.org/docu/files/api/index.html) you can send > messages remotely. But I think it is using Java serialization/ > deserialization and personally I'd stay away of this. I'd probably use > other transports like AMQP or REST and keep working with actors > locally. > > For terracotta you can read more here:http://www.terracotta.org/... > it is a great framework. > > > > > On Jul 9, 11:53 pm, "marius d." <[email protected]> wrote: > > > > Actors are local to the JVM. Scala also has RemoteActors but we don't > > > really use them. For a lift app in a cluster environment we have to > > > have sticky sessions concept and the reason is that functions bound to > > > a session and mostly the references they are holding are not > > > serialized & distributed. So assuming: > > > > 1. Session 1 is created on Node 1 > > > 2. If on a subsequent request (pertaining to the Session 1) load > > > balancer decides to dispatch the request on Node 2 you are loosing all > > > session context including bound functions etc. > > > > This is why the load balancer must guarantee that all requests > > > pertaining to the same session needs to be dispatched on the same > > > node. > > > > There were some efforts in the past to integrate Terracotta but I > > > guess there was a dead end somewhere. > > > > You can of course build you own app to not use functions bound to a > > > session and only rely on DispatchPf style (somehow similar with Spring > > > controllers) but that's not very lift-ish. But in this case you can > > > persist your state in DB (which is common to all nodes) and when a > > > request comes you just fetch the context data from DB and set your > > > SessionVars. The problem with functions kept on the session is that > > > those function can be lambda expression referencing members from other > > > classes which are not serializable etc. And even if they somehow were > > > Java serialization is bad for performance. > > > > The bottom line is that sticky sessions have the benefit of the > > > performance because there is no state that needs to be distributed and > > > replicated among all cluster nodes OR no need to persist the session > > > state. But the drawback is that requests pertaining to the same > > > session needs to be processed by the same node. > > > > IMHO using Lift apps in a cluster env. without sticky sessions can be > > > a very tricky thing to achieve. > > > > Br's, > > > Marius > > > > On Jul 10, 6:32 am, DFectuoso <[email protected]> wrote: > > > > > I'm hosting some experiments on Stax and right now im pondering over > > > > the idea of checking out how to have a database backed session so the > > > > SessionVars work in a cluster of 5 boxes; With that in mind, have > > > > anyone worked with actors and clustering? Is there some documentation > > > > around that? should it work out of the box, or some works of > > > > encouragement to try working on this terrain?
--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
