Reactors.IO: Actors Done Right

Table of contents

Reading Time: 6 minutes

In our previous blog, we tried to explore the upcoming version of i.e Java 9. So this time we try to focus on Scala . In This Blog , We will be Looking onto a New Reactive programming framework for Scala Applications i.e Reactors IO .

Reactors.io fuses the Best parts of Functional reactive Programming and the Actor Model.
Reactors allows you to create concurrent and distributed applications more easily, by providing correct, robust and composable programming abstractions.Primarily targeting on JVM , the Reactors framework has bindings for both Scala and Java.

Setting Up Reactors.io

To get started with Reactors.IO, you should grab the latest snapshot version distributed on Maven. If you are using SBT, add the following to your project definition :

Then Simply Import the io.reactors package: import io.reactors._ and you are ready to go.

Why Reactors?

Areas Where Actors Lack :

First, in the basic actor model, actors cannot simultaneously contain multiple message entry points
Second , actors cannot await specific combinations of messages
Third, receive is not a first class entity. Instead of a value that can be passed to and returned from functions, receive is a static construct.

These limitations make Protocol Composition within a single actor cumbersome, convolute abstractions and restrict code reuse.The model is sufficiently low-level to express arbitrary message protocols. Composing these protocols is the key to high-level abstractions. Therefore, it is difficult to reuse or compose message protocols with actors.
Reactors simplify protocol composition with first-class typed channels and event streams.

Reactor Characteristics

Event Driven:

Reactors comprise an event-driven programming model. Clients can subscribe and react to event streams, which asynchronously produce events. This makes the reactor model well-suited for interactive applications , but also ideal for building distributed software, which is typically characterized by latency and asynchrony.
After an event arrives, it gets forwarded to the observers of that event stream.
Concurrent and distributed :

The reactor model organizes computations into basic units of concurrency called reactors. Inside each reactor, computation is sequential.
At the same time, the reactor model is quite location-transparent. This means that you can develop and test the program on a single machine, and then seamlessly deploy it on multiple machine that are connected with a computer network.
First class :

While the concept of event streams and callbacks resembles the principles found in traditional actor systems , event streams are first-class, functional values.
They can be declaratively composed and manipulated in a similar fashion as Scala collections or Java streams.First-class events streams and signals allow a better separation of concerns.
Modular :

Components are expressed as event stream operations, which can be packaged into modules, and later reused or further composed.The subtle interplay between channels and event streams allows composing powerful event exchange protocols in a modular fashion.

Actors vs Reactors

Actors	Reactors
Actors receive messages	Reactors receive events
An actor in particular state has only a single point in its definition where it can receive a message.	A reactor can receive an event from many different sources at any time.
Receive all types of messages	Receive events only of Defined(T) Type in Reactor.apply[T] (Eg. String)
It difficult to reuse or compose message protocols with actors.	Comparatively , Protocol composition is much simpler in case of reactors.

Reactor System Basics

Event streams :

Event streams are objects that may asynchronously publish events. Event streams are entities that propagate events within a reactor, and they cannot be shared between reactors. An event stream is associated to every channel. Event streams can be used as we use collections in Scala.

Channels :

Reactor’s means of communicating with its environment.
Every reactor is created with a default channel called main, which is usually sufficient.
Every channel is owned by a single reactor.
Any reactor can send an event to a channel, but only the channel owner can process that event.

Schedulers :

Schedulers in Reactor Model basically help in assigning a thread to the events so that they can be executed i.e. helps in Resource Management.
Every reactor system is bundled with a Default scheduler and some additional predefined schedulers. When a reactor is started, it uses the default scheduler, unless specified otherwise.

Reactor LifeCycle

Every reactor goes through a certain set of stages during its lifetime, jointly called a Reactor Lifecycle. When the reactor enters a specific stage, it emits a lifecycle event. All lifecycle events are dispatched on a special daemon event stream called sysEvents. Every reactor is created with this event stream.

Reactor System Services

The Logging service :

The Logging service is used to print logging messages to the standard output

The Channels service :

The Channels service provides an event-driven view over all channels that exist in the current reactor system.This allows polling the channels that are currently available, or waiting until a channel with a specific name becomes available.

The Clock Service :

The Clock service is capable of producing time-driven events, for example,timeouts, countdowns or periodic counting.The Clock service uses a separate timer thread under the-hood, which sends events to the reactor when the timer thread decides it is time to do so.

Protocols

Set of Predefined Rules Provided by the Reactor System in order to ease the understandings and also to maintain certain standards for successfully creating concurrent and distributed applications.
The communication protocols are composed from basic abstractions and simpler protocols.

There are various protocols provided by the Reactor Model .

The Basic Among Them Include :

Standard server-client protocol :

The Standard Server- Client Protocol relies solely on the basic primitives provided by the Reactors framework. This Protocol is the Basis for other Protocols and it can also be modified or customized easily according to our requirements thus turning into a Custom Client-Server Protocol

Router Protocol :

Events coming to a specific channel are routed between a set of target channels, according to some user-specified policy.(Round-Robin , Hash , Random)
Applications :

- Data replication and sharding
- Load-balancing
- Multcasting

2-Way Communication Protocol

In two-way communication, two parties obtain a link handle of type TwoWay, which allows them to simultaneously send and receive an unlimited number of events, until they decide to close this link.
The TwoWay object contains an output channel Output, and an input event stream Input.
To close the link, the TwoWay object contains a subscription object called Subscription, which is used to close the link and free the associated resources.

Limitations : Not Everything is Perfect

Reactors may overcome many problems of the traditional actor system but still lack certain things. One of the major among them is :

– Missing Resilience ( The ability to overcome from a crash or problem)
i.e No supervision as provided by Akka.
– Still under development and many features are still missing and hopefully will be updated soon.