forked from laforge49/JActor
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
113 lines (83 loc) · 4.87 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
The JActor project implements actors in Java that can process 1 Billion messages per second.
Downloads: https://sourceforge.net/projects/jactor/files/
Blog: https://sourceforge.net/p/jactor/blog/
API: http://jactor.sourceforge.net/
VCS: https://github.com/laforge49/JActor
Issues: https://github.com/laforge49/JActor/issues
free(code): http://freecode.com/projects/jactor
Google groups: http://groups.google.com/group/agilewikidevelopers
Dependent Projects
- Incremental Deserialization https://github.com/laforge49/JID
Available on The Central Repository (Maven): http://search.maven.org/#search|ga|1|g%3A%22org.agilewiki%22
So you just need to add this to your POM file:
<dependency>
<groupId>org.agilewiki.jactor</groupId>
<artifactId>jactor</artifactId>
<version>1.4.0</version>
</dependency>
(Be sure to update the version number appropriately, of course.)
This project is a reimplementation of a portion of the AsyncFP Scala project:
https://github.com/laforge49/Asynchronous-Functional-Programming/wiki
Message passing between actors mostly uses 2-way messages (request / response). There are several
reasons for this:
o With 2-way messaging, sending a request is very similar to a method call with a
callback. Most requests are processed synchronously, which is why JActor is so much
faster than other actor implementations.
o Mailboxes are used mostly when passing messages between threads and are first-class
objects. As first-class objects, mailboxes can be used by more than one actor. Passing
messages between actors with a common mailbox is always done synchronously and is very
fast.
o Flow control is implicit to 2-way messaging. Systems with good flow control are
generally well-behaved when operating with a full load.
Two-way messaging is so much faster than 1-way messaging that it is practical to use
2-way messages when only 1-way messages are needed. There is however one case where you
shouldn't use 2-way messages: when events from non-actor code need to be sent to an actor.
The JAEvent class is used to do this.
Exception Handling
The extensive use of callbacks complicates control flow, which is only made worse with some
callbacks being executed asynchronously. Exception trapping then can be quite error prone. So
exception handling is supported. A default exception handler is also provided which passes any
uncaught exceptions that occurred while processing a request back to the actor which sent the
request, recursively.
Bi-Modal Iterator
Loops with 2-way messages can be problematic, as iterations typically must wait for the
response from the previous iteration. A bi-modal iterator is provided to cover this. Each
iteration takes 5 nanoseconds for synchronous responses and 8 nanoseconds when a response
is asynchronous.
State Machine
State machines are often used with actors and can add considerable clarity to the code. JActor
includes classes for composing and executing state machines that are compatible with 2-way
messages.
Dependency Injection
If an actor receives a request of a type that it does not recognize and that actor has been
assigned a parent actor, then the request is immediately forwarded to the parent actor.
Request Message Binding and Actor Composition
Actors can be composed from one or more components, where each component maps the request
classes that it handles to the logic for processing those requests.
Components
Several components are provided:
ActorName - Used to assign a name to an actor.
ActorRegistry - Locates actors by name and closes them when the registry is closed.
Factory - For creating actors with a single component include.
Properties - For creating a table of name/value pairs.
PubSub - Publish and subscribe.
Message Passing Benchmarks
When actors share the same mailbox, 1,095,890,410 messages are passed per second. With a
response time of 7.6 nanoseconds.
When different mailboxes are used, the rate drops to 71,095,312 per second and the response
time becomes 56 nanoseconds.
Asynchronous message passing is also supported, making it easy to use all the available
hardware threads for good vertical scalability. Messages sent to an actor with an
asynchronous mailbox are passed asynchronously at a rate of 42,149,631 per second. The
response time is 996 nanoseconds.
PubSub Component Benchmarks
For shared mailboxes, 81,799,591 publications per second
and a response time of 49 nanoseconds.
With different mailboxes, 31,595,576 publications per second
and a response time of 168 nanoseconds.
And with asynchronous mailboxes, 11,305,822 publications per second
and a response time of 1.5 microseconds.
Test Environment
Tests were done on an Intel Core i5 CPU M 540 @ 2.53GHz, which has 4 hardware threads. The
times reported were best run in 5. Only standard switch settings were used--there was NO
compiler optimization.