Play 2 with Akka - Statelessness and scaling issues

1
votes

I thought that one of the advantages of using a stateless web framework such as Play was that a load-balancer could send requests to any node and not be concerned with which node receives the request. I am concerned about how Akka integration affects statelessness. By spawning an actor using the built-in system, aren't I potentially creating state that lives beyond a single request and is tied to a single instance of the application?

I think it would be fairly common to want to spawn an actor that lives beyond a single request and is accessible from multiple application instances. Is there a common pattern for accomplishing this? Would it be necessary to use a remote actor system for spawning this actor or can the local built-in play system be used in some way?

1
playframeworkplayframework-2.0akka
Actors aren't inherently stateful. One possibility is to spawn the actor on each node but keep the state in a distributed cache (e.g., Redis). - Ryan
are you talking about a multi or single-node system? - sourcedelica
@sourcedelica There are multiple play applications running. Each of these instances has its own JVM and actor system. Part of what I am trying to figure out is if it necessary for there to be at least one additional non-Play node. - mushroom
@Ryan In the particular scenario I am imagining, a new actor is spawned as the result of a request. - mushroom
Unless you need that actor to persist for the user's next request, it doesn't matter. - Ryan

1 Answers

1
votes

In the simplest setup you could have the stateful actor running at a known hostname/port and known actor path. For example, it could be located at "akka.tcp://[email protected]:2552/user/statefulActor". Then on each of your play systems you would look up this actor and your stateless actors could send messages to it. The stateful actor(s) could be running inside one of your play actor systems. You wouldn't need to create a separate actor system.

The problem with the simple setup is that it's a single point of failure. This may or may not be an issue for you. For a more robust approach, see the Cluster Singleton Pattern.