On Jul 10, 10:40 am, DFectuoso <santiago1...@gmail.com> 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." <marius.dan...@gmail.com> 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 <santiago1...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
