The Basic Ideas To better understand why and when clustering architecture should be adopted, the below subsections show the benefits of actor model in general, its remoting architecture, and its clustering architecture. Actor Model in General With the power of actor model, a developer has easier access to concurrent programming. The actor can keep mutable state, and its messaging queue – a mailbox – guarantees messages are passed to the actor one at a time. Read more...

Chat Example Using Proto.Remote In this example, we are going to go beyond Proto.Actor and leverage Proto.Remote package in order to enable bidirectional communication between different actors in a client to server fashion. These actors might be living inside of separate actor systems partitioned by a network (potentially located on different machines) and as a result of this, we are actually going to demonstrate how easy it is to create a basic but functional distributed system of actors by using just a couple of Proto features. Read more...

Context Proto.Actor provides two forms of Context, a RootContext and an ActorContext. These contexts are composed of various functionality provided by distinct facets. Both types of context implement Spawner, Stopper, Info and Sender facets, while the ActorContext implements additional facets. Root Context Facets Spawner Stopper Info Sender Actor Context Facets Spawner Stopper Info Sender Receiver Invoker Supervisor Context Facets Spawner Implemented by RootContext, ActorContext Read more...

Local Affinity Virtual Actors with locality to Kafka consumer Local Affinity placement enables us to place virtual actors in the locality to some other resource. In this example, we place the virtual actors close to an Apache Kafka consumer. The actors on the same cluster member, will only be actors that consume messages from the partitions of this specific Kafka consumer. Scale up or down In case there is a scale up or down scenario, some of these actors will now be on the original node where they first spawned. Read more...

Actors An actor is a container for State, Behavior, a Mailbox, Children and a Supervisor Strategy. All of this is encapsulated behind a process ID (PID). PID - Process ID As detailed below, an actor object needs to be shielded from the outside in order to benefit from the actor model. Therefore, actors are represented to the outside using PID’s, which are objects that can be passed around freely and without restriction. Read more...

Performance and Benchmarks Lib Remote PingPong Inproc PingPong SkyNet Proto.Actor C# ~8 500 000 msg/sec ~125 000 000 msg/sec ~0.5 sec Proto.Actor Go ~5 400 000 msg/sec ~70 000 000 msg/sec ~1.2 sec Akka.NET ~350 000 msg/sec ~46 000 000 msg/sec ~4.5 sec Erlang ~200 000 msg/sc ~12 000 000 msg/sec ~0.75 sec Remote PingPong This test uses two nodes and two actors, one on each node. Read more...

Related material Manning Publications Co. Akka in action Functional and Reactive Domain Modeling Functional Reactive Programming Reactive Application Development Reactive Design Patterns

Design principles Proto.Actor was born in the Go ecosystem, these design principles was set on day one to conform to the Go mindset. Constraints Minimalistic API Don’t bloat the API, avoid enterprisey JVM like containers and configurations. Offload features like logging, configuration, scheduling and dependency injection to 3rd party libraries. they are not part of the core problems solved by the framework. The API should be small and easy to use Read more...

Message Delivery Reliability Proto.Actor helps you build reliable applications which make use of multiple processor cores in one machine (“scaling up”) or distributed across a computer network (“scaling out”). The key abstraction to make this work is that all interactions between your code units—actors—happen via message passing, which is why the precise semantics of how messages are passed between actors deserve their own chapter. In order to give some context to the discussion below, consider an application which spans multiple network hosts. Read more...

Fault Tolerance Each actor is the supervisor of its children, and as such each actor defines fault handling supervisor strategy. This strategy cannot be changed afterwards as it is an integral part of the actor system’s structure. Fault Handling in Practice First, let us look at a sample that illustrates one way to handle data store errors, which is a typical source of failure in real world applications. Of course it depends on the actual application what is possible to do when the data store is unavailable, but in this sample we use a best effort re-connect approach. Read more...