Thanks, that was very useful, to enable sticky variables i would do something like (explain here http://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) 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 -~----------~----~----~----~------~----~------~--~---
