Reactors.io

REACTORS.IO
By :-
Anmol Sarna
Software Consultant
KNOLDUS SOFTWARE LLP

Agenda
● What Are Reactors ?
● Setting Up Reactors.io
● Why Reactors ?
● Reactor Characteristics
● Actors vs Reactors
● Event Streams
● Using Channels
● Schedulers And Reactor LifeCycle
● Reactor System Services
● Introduction To Protocols
● ShortComings in Reactors

Reactors : Actors Done Right
Actors : Basic Units of Concurrent Execution
Reactors : Basic Units of Concurrent Execution which can
perform computations as well.
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.
(Reactive programming framework for Scala)

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.

Concurrent and Distributed Programs : A
headache?
First of all, most concurrent and distributed computations are by nature non-
deterministic. This non-determinism is not a consequence of poor programming
abstractions, but is inherent in systems that need to react to external events.
Data races are a characteristic of shared-memory multicore systems. Combined with
inherent non-determinism, these lead to subtle bugs that are hard to detect or
reproduce.
Shared-memory programs do not work in distributed environments, and existing
shared-memory programs are not easily ported to a distributed setup.
It is extremely hard to correctly compose concurrent and distributed programs.
In Short , Costly And Hard to get right

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.
Why Reactors?

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.

Reactor Characteristics (Cont.)
● 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.

Reactor Characteristics (Cont.)
● First class and Modular
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.
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.

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.
● Lifecycle of an event stream :
The Observer[T] type has three methods:
- react: Invoked when a normal event is emitted.
- except: Invoked when the event stream produces an exception.
- unreact: Invoked when the event stream unreacts, i.e. stops producing events. After this , no further
events nor exceptions will be produced by the event stream.
● Higher-order event streams :
Event streams that produce events that are themselves event streams. A higher-order event stream
can have a type such as this one:
Events[Events[T]] (Code)

Using Channels
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.
But sometimes a reactor needs to be able to receive more than just one type of
an event, and needs additional channels for this purpose.
(Code)

Schedulers
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.
Example : In this , we override the default scheduler with the one using Scala’s
global execution context, i.e. Scala’s own default thread pool :
val proto =
Proto[DemoClass].withScheduler(JvmScheduler.Key.globalExecutionContext)
(Code)

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.
(Code)

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.
(Code)

Introduction To Protocols
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.
Standard server-client protocol :
Relies solely on the basic primitives provided by the Reactors framework.
These can be modified or customized easily according to our requirements.
(Code)

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
( distributing data across
multiple machines )
- Load-balancing
- Multicasting
(send data across a computer
network to several users at the
same time)
(Code)

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.
One party initiates the link, so we call that party the client, and the other party the
server.
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.
(Code)

Not Everything is Perfect !!!
Reactors may overcome many problems of the traditional actor system but still
lack certain things. Some of them are :
● Missing Resilience ( The ability to overcome from a crash or problem)
No supervision as provided by Akka
● Location Transparency Not as Good as Actor Model
Reactor programs can be implemented on a single machine and then
deployed on multiple
machines connected with a network but not as easily as compared to
actors
● Still under development and many features are still missing and hopefully
will be updated soon .

References
● Reactors.io
● Reactors, Channels, and Event Streams for Composable
Distributed Programming (PDF)
- By Martin Odersky and Aleksandar Prokopec

Reactors.io

More Related Content

What's hot (20)

Similar to Reactors.io (20)

More from Knoldus Inc. (20)

Recently uploaded (20)

Reactors.io

Editor's Notes