Supporting Relative Location Constraints in Actor Systems
Hua Zhang
Nadeem Jamali
Xinghui Zhao
School of Engineering and Computer Science
Washington State University
14204 NE Salmon Creek Ave.,
Vancouver, WA 98686
{hua.zhang, x.zhao}@wsu.edu
Abstract
The Actor model supports mobility of computations, and in actor migrations, absolute destinations must be explicitly specified.
However, in many real world applications, relative location relationships are more meaningful. In this paper, we propose a middleware which supports relative location constraints of actors. We use
a case study to illustrate that our middleware greatly enhances the
flexibility and programmability of actor systems. In addition, experimental results show that our middleware platform is scalable.
Categories and Subject Descriptors D.1.3 [software]: Programming Techniques—Distributed Programming; D.3.4 [software]:
Processes—Run-time Environments
General Terms Languages, Experimentation, Performance
Department of Computer Science,
University of Saskatchewan
176 Thorvaldson Building, 110 Science Place,
Saskatoon, Canada, S7N 5C9
[email protected]
AKKA [3] actor systems, as shown in Figure 1. The Constraint
Management Middleware (CMM) consists of three components: a
list of Constraints that are currently enforced, a Yellowpage which
maintains the topology of the physical nodes/machines in the runtime system, and a CSP Solver, the key component which models
the problem as a constraint satisfaction problem (CSP), solves it,
and generates feasible deployment plans for actors.
Constraint Management Middleware
Actor
Programs
+
Constraints
AKKA Runtime System
Node 2
CSP
Solver
Node 1
Node 3
Constraints
Yellowpage
...
Keywords Actors, Constraints, Mobility
1.
Introduction
The growing ubiquity of big data applications results in renewed
interests in the mobility of computations. This is because moving
required data to computations is no longer a viable solution, instead, computations themselves should be migrated to the location
where the required data reside. The Actor model [1], which supports live migration of computations, provides a convenient way
to program such mobile computations. However, the fact that an
absolute destination location must be specified in an actor migration limits the flexibility of actor systems. In this paper, we address
this challenge by developing a middleware which supports various
types of relative location constraints for actors, and enforces those
constraints at run-time.
2.
Constraint Management Middleware
Separation of concerns has long been a widely used design principle in software engineering. It has been shown that spatial relationships of computations can be specified and maintained separately
from the computations [4] for enhanced programmability. Inspired
by this work, we have designed and implemented a middleware for
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from [email protected].
SPLASH’14, Portland, OR.
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM [to be supplied]. . . $15.00.
http://dx.doi.org/10.1145/2541329.2541337
Figure 1. Constraint Management Middleware
As shown in Figure 1, CMM takes as input actor programs and
user-defined constraints, which can be specified in either a static or
a dynamic way. A static constraint specification is in the form of a
separate constraint configuration file, which lists actor names and
their relative location constraints. This form is suitable for specifying predictable, fixed constraints. For instance, a computation
actor should be collocated with the data that it requires. In contrast, a dynamic constraint specification can be combined in the
actor program, so that constraints can be dynamically generated at
runtime. This form is particularly useful when the location constraints evolve during the course of the computation, i.e., location
constraints need to be programed. For example, a data aggregation
actor should initially be placed at a location close to the actors from
which it collects data; however, after the data has been collected, it
is free to move elsewhere for other purposes. Table 1 shows a list
of possible relative location constraints for actors.
Table 1. Relative Location Constraints for Actors
Constraints Parameters
Description
separate
a1 , a2
a1 a2 are separated
collocate
a1 , a2
a1 a2 are collocated
within
a1 , a2 , d
distance ¤ d
outof
a1 , a2 , d
distance ¡ d
isolate
a1
a1 is isolated from other actors
The CSP Solver uses a customized backtracking-search algorithm [5] to solve the constraints, as shown in Algorithm 1. Note
that heuristic approaches can be used in the algorithm to choose
Algorithm 1: CSP Solver(constraints, yellowpage, map)
if all actors have been deployed then
return map;
end
else
get the next actor a;
end
for each node in possible locations(a, map, constraints) do
if place a to node is consistent with map then
place actor a to node;
derive the inferences of the deployment;
if inferences do not lead to failure then
add inferences to map;
result = CSP Solver(constraints, yellowpage,
map);
if result != failure then
return result;
end
end
end
remove deployment of a and its inferences from map
end
return failure
We first run the computation in the original AKKA platform
with 3 physical nodes. In this case actors are randomly distributed on 3 nodes. We then run the same computation on CMM,
with one location constraint which is collocate(mapActor,
dataActor). In this way, the computations are collocated with
the data that they require. Figure 2 shows the results of the experiments with different file sizes. When the file size increases, we can
achieve an order of magnitude of performance gain using CMM,
with no added programming complexity. Only a static constraint is
needed.
3.2
Scalability Analysis
The case study only uses one single constraint. To evaluate the scalability of CMM, we have carried out another set of experiments. In
these experiments, we randomly generate a number of constraints,
and use CMM to generate and enforce a deployment plan. We then
measure the performance of CMM, and the results are shown in
Figure 3, which demonstrates that CMM scales well when the number of constraints increases.
60 Performance (ms) potential locations for an actor. In addition, the complexity of the
algorithm can be reduced by deriving inferences from certain types
of constraints, e.g., collocate, as suggested in [4].
50 40 30 20 10 0 100 200 300 400 500 600 700 800 900 1000 Number of Constraints Once a valid solution map is generated by the CSP Solver,
CMM informs AKKA runtime system to deploy actors based on
the solution. CMM is extendable in terms of constraints. In other
words, users can easily accommodate more user-defined constrains
by modifying the consistency checking method in CSP Solver.
Figure 3. Scalability of CMM
4.
3.
Experimental Results
Experiments have been carried out to evaluate the effectiveness and
scalability of our approach.
3.1
A Case Study: Word Count
In this case study, we use AKKA actor system and CMM to implement word count, a Map-Reduce application. The application
counts the number of occurrences of each word in a file. We implement the application as follows. A dataActor is responsible for
maintaining the files, and sending the files to other actors which
require them. The actual computation is carried out by a number
or mapActors and reduceActors, as would be done in MapReduce [2].
References
[1] G. A. Agha. Actors: A Model of Concurrent Computation in Distributed
Systems. MIT Press, Cambridge, 1986.
[2] J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on
Large Clusters. Communications of the ACM, 51(1):107–113, 2008.
30000
25000
Performance (ms)
Conclusion and Future Work
The Actor model supports mobility of computations; however, its
implementations often require users to explicitly specify the destination of actor migration, which unnecessarily limits the flexibility
actor systems. In this paper, we present a Constraint Management
Middleware (CMM), which enables users to program relative location relationships among actors, and enforces these location constraints at runtime. CMM on AKKA actor systems shows good
scalability, as well as potentials of enhancing programmability and
performance of actor systems. Work is ongoing to extend CMM by
accommodating other types of constraints, such as real-time constraints. In addition, we will use the extended CMM to solve problems in mobile clouds and other environments.
20000
AKKA
15000
CMM
10000
5000
0
0
50
100
150
200
250
File Size (MB)
Figure 2. Performance Comparison – Word Count
[3] M. Gupta. Akka Essentials. Packt Publishing Ltd, 2012.
[4] N. Jamali and A. Keela. Maintaining spatial relationships in uncertain
environments. In Proceedings of the Sixth International Conference on
Self-Adaptive and Self-Organizing Systems (SASO 2012), pages 227–
228, Lyon, France, September 2012. IEEE Press.
[5] S. J. Russell and P. Norvig. Artificial Intelligence: A Modern Approach.
Pearson Education, 2 edition, 2003.