Re: [nodejs] An actor model in node.js

[codepilot Account]

VHDL

On Sun, Jun 17, 2012 at 12:50 AM, Paul Miller <paulp...@gmail.com> wrote:

So, as you know, erlang is great because of this one.

Are there any great actor model implementations currently that will allow you to spawn tens of thousands of processes without bullshit?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Angel Java Lopez]

Interesting. I have few to have an answer... but I could add only some comments, related to my pet projects, work.

I think that in Node.js world, we should separate:

- local actor implementation

- remote communication

The second point could be resolved with RPC or something alike. Candidate: dnode. But we should manage disconecction, new node instances, etc...

I tried the first point in my pet project:

https://github.com/ajlopez/SimpleActors

There is a local actors web crawler example. Now, there is a remote example, that could be implemented with dnode, but I am playing with another of my projects for remote object ("dog fooding" ;-)

But, we could have message passing, without having an actor an explicit reference to another actor. I think that is the way of Storm

http://storm-project.net/

in Java World. A simple implementation with local web crawler example:

https://github.com/ajlopez/SimpleStorm with one spout and many kind of bolts.

I should add the "distributed" ingredient to such topology. A two? three? pipe problem? (no pun intended) ;*)

But another way, without an explicit topology, only messages, and node instances that communicates what kind of messages they can process:

https://github.com/ajlopez/AjFabriqNode

I guess this way has more resilience to the add/remove of running node instances.

Interesting topic Paul!

Angel "Java" Lopez

http://ajlopez.wordpress.com

http://twitter.com/ajlopez

[George Stagas]

Paul, take a look at https://github.com/stagas/drama

It's a full-featured actor framework heavily inspired by Scala Actors and Akka.
You can effortlessly spawn as many actors as you need, in both server
side (in-process or forked) and client side (using socket.io or
websockets) or your own custom interfaces and mix and match any of
those seemlessly.
Documentation is yet to come, but you can take a peek at the examples
https://github.com/stagas/drama/tree/master/examples it shouldn't be
too hard.

2012/6/17 Paul Miller <paulp...@gmail.com>:

[Alexey Petrushin]

I'm not sure that Reactor (Node.js) should be used with Actors. It seems that it's a different approaches for solving the same problem - concurrency.

If JS would have ability to spawn tons of cheap processes - then we just don't need such limitation as Node.js async API.

So, it seems it's not just a question of some sort of lib for node.js - but more like a completely different API on top of Node.js (or instead of Node.js).

[Tristan Slominski]

I haven't taken it up to tens of thousands of processes, but here's my pet project:

https://github.com/tristanls/anodejs

It naively uses process.nextTick for sending a message, which negatively affects performance (the correct answer is an optimisation based on what node.js release you have that would process an x number of messages per tick and then yield via process.nextTick). Also, unlike the drama that stagas mentioned, this is only for local machine without remoting.

[Matthew Browne]

Hi,
I realize this thread is a little old, but I just came across it I don't understand your reasoning...yes, Reactor (event loop-based approach) is a different approach than Actors, but Actors have been implemented successfully on top of event loops in some other languages like Python and have achieved very good concurrent performance (from what I can gather anyway).

The main drawback is that you no longer have parallelism across multiple cores, but in node.js we've already accepted that and are willing to settle for separate OS processes instead.

The only real disadvantage I can think of is that the node.js API is designed to be used with callbacks, but for one's own application code (especially the parts that are straight JS that don't use the node API as much) it seems like an actors library like drama is a great approach to concurrency (and asynchronous OOP).

[Tristan Slominski]

In this context, implementing actors can be thought of as a pattern. I've implemented actor frameworks from scratch on a number of different "substrates". Much like one can implement a JVM in JavaScript, one can implement an actor system on top of Node.js. All the way down, something must animate the actor framework. All the way down, things tend to run in assembly on hardware. How many layers between the hardware and your actor framework and what conveniences you want to include with that are up to you. 

Another way to phrase the issue, an actor framework can be a meta-layer on top of Node.js reactor setup. If the use of actors helps to reason about the problem in better ways, that's part of the cost benefit analysis of solving the problem with actors.

You could also go as far as Coffeescript did and implement an [actor] language using Node.js' reactor, I'd probably use OmetaJS here. 

Lastly, my usual criticism, Akka (inspiration behind drama) is popular, but it gives up Object Capability, which actor systems start off with. Object Capability allows you to _prove_ (as in mathematical proof) security properties of an actor configuration. Framework implementations of actors tend to sacrifice Object Capability for, in my opinion, dubious benefit.

[Matthew Browne]

Hi Tristan,
Thanks for the clarification.

I was wondering, do you think it might be useful to implement Actors using the fibers module (https://npmjs.org/package/fiber)?

I noticed that there's an Actors lib for Ruby implemented with fibers:
https://github.com/tarcieri/revactor

It seems like this might make concurrent programming a bit easier in node.js and help avoid callback pyramids. What do you think?

Thanks,
Matt

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 

---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/iHSkdmGaRnk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mark Hahn]

I have heard that actors such as used by Apple are slow.  Is this true in general?

You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

[Matthew Browne]

On 7/26/13 3:12 PM, Mark Hahn wrote:

I have heard that actors such as used by Apple are slow.  Is this true in general?

I am just learning about actors myself, but the comparisons I've seen online between event loops and actors generally seem to suggest that actors are equally fast as event loops, if not faster. Of course, take that with a grain of salt - hopefully someone with more experience will comment.

One nice thing about actors is that they're really the essence of object-orientation - a network of communicating objects / actors, each of which is like a mini-computer, that communicate via messages. This was the vision expressed by Alan Kay, who invented the term "object-oriented programming."

This is not to say that OOP is always the "best" solution, but it's certainly a powerful idea, and quite useful in a lot of situations, when its original meaning is understood, rather than the watered-down version (which is really class-orientation) that's more common today. The parallels with actors are quite strong...

Alan Kay:

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole--like data structures, procedures, and functions which are the usual paraphernalia of programming languages--each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm--which I called object-oriented--for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modelling the ever more complex dynamic systems and user relationships made possible by the silicon explosion.

[Kay-93]

Carl Hewitt:

"An Actor is the fun­da­men­tal unit of com­pu­ta­tion which embod­ies the 3 things – pro­cess­ing, stor­age and com­mu­ni­ca­tions – that are essen­tial to computation."

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

Trygve Reenskaug, inventor of the MVC pattern and DCI:

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating:

(from a draft article as quoted here:)
https://groups.google.com/d/msg/object-composition/N5D3eBCvZhE/afCxLAE58joJ

[Norman Paniagua]

This concept its new for me, but as far as I read this approach it good to solve other problems that cannot be solved with the traditional paradigm. In my case I need a system that can run continuous and can be fault tolerant, maybe its more memory expensive this approach but in terms of system stability and zero downtime seem to be good.

Another think I like its to learn the way that this methodology works, starting maybe a prototype project. Seems that some people try the same but seems that their projects are not popular or poorly maintained (I just see the commits and contributors of each and its to low).

Someone has experience with those kind of frameworks? (not specifically using nodejs, can be also with other languages too, I want advices and/or articles that discuss about this).

Regards

PD: I just start reading ACTORS: A Model of Concurrent Computation in Distributed Systems (free available at MIT site)

[Matthew Browne]

If you want to learn more about the actor model, I highly recommend looking into some resources by its creator, Carl Hewitt. In particular, check out this video:

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

Here's his original 1976 paper introducing the actor model:
http://dspace.mit.edu/handle/1721.1/6272#files-area

I still think creating an actor library on top of fibers would work great for node.js but I haven't had a chance to try it out yet...does anyone else agree that this is a good idea?

[Norman Paniagua]

Thanks for the resources…

I read somewhere in this groups that c extensions may slow down nodejs, and fibers just is written in c++, don't know yet how it may affect the performance of the app that uses it.

Regards

-- 

Norman Paniagua

[Tristan Slominski]

Hey Norman,

I highly recommend Dale's blog series on Actors: http://www.dalnefre.com/wp/  (start with oldest and work your way forward in time). It is well documented with lots of references to interesting writings. 

In particular to your comment on "I need a system that can run continuous and can be fault tolerant" you may want to take a look at the Ken protocol: https://www.usenix.org/system/files/conference/atc12/atc12-final206-7-20-12.pdf

From the website (http://ai.eecs.umich.edu/~tpkelly/Ken/):

Ken is a lightweight C implementation of a rollback-recovery protocol that provides crash-restart resilience to distributed applications. Ken unifies and automates reliability for both application data "at rest" (local process state) and data "in motion" (messages in a distributed system). Ken ensures that crash-restart failures (power failures, kernel panics, process crashes) can't corrupt or destroy data, and Ken guarantees that messages are reliably delivered and processed by recipients in process-pairwise-FIFO order. Ken furthermore provides strong global correctness guarantees and prevents crash-restart failures and packet losses from causing a distributed system to emit incorrect outputs. Finally, Ken's strong guarantees compose effortlessly when independently developed Ken-based distributed systems are integrated.

I'm happy to discuss more specifics if you'd like.

Cheers,

Tristan 

[Alexey Petrushin]

I'd personally prefer actor to reactor because it's simpler to use. For me working with isolated independent things is much simpler than with state machine and recursions.

As about the performance - I don't care much, node already fast enough.

[Matthew Browne]

On 9/25/13 9:06 AM, Alexey Petrushin wrote:

I'd personally prefer actor to reactor because it's simpler to use. For me working with isolated independent things is much simpler than with state machine and recursions.

I agree. Events can help prevent callback pyramids to some degree, but with actors you can write code just as if it were synchronous; it's just simpler.

In terms of the API for a new actors library for node.js, I was thinking of something similar to this Ruby library:
http://celluloid.io/

That library uses threads, but the same author previously wrote a library implemented using fibers, which could serve as a model for node.js (since obviously we don't have or want threads):
https://github.com/tarcieri/revactor

On 9/24/13 1:56 PM, Norman Paniagua wrote:

Thanks for the resources…

I read somewhere in this groups that c extensions may slow down nodejs, and fibers just is written in c++, don't know yet how it may affect the performance of the app that uses it.

Thanks for mentioning this. There's at least one significant framework already using fibers (Meteor) and I haven't heard anything about it being slow, but we should keep this in mind because it would be ideal if the actor library were just as fast as native node.js.

On Wednesday, July 24, 2013 9:17:24 AM UTC+4, Matthew Browne wrote:

Hi,
I realize this thread is a little old, but I just came across it I don't understand your reasoning...yes, Reactor (event loop-based approach) is a different approach than Actors, but Actors have been implemented successfully on top of event loops in some other languages like Python and have achieved very good concurrent performance (from what I can gather anyway).

The main drawback is that you no longer have parallelism across multiple cores, but in node.js we've already accepted that and are willing to settle for separate OS processes instead.

The only real disadvantage I can think of is that the node.js API is designed to be used with callbacks, but for one's own application code (especially the parts that are straight JS that don't use the node API as much) it seems like an actors library like drama is a great approach to concurrency (and asynchronous OOP).


On Monday, June 18, 2012 11:50:41 AM UTC-4, Alexey Petrushin wrote:

I'm not sure that Reactor (Node.js) should be used with Actors. It seems that it's a different approaches for solving the same problem - concurrency.

If JS would have ability to spawn tons of cheap processes - then we just don't need such limitation as Node.js async API.

So, it seems it's not just a question of some sort of lib for node.js - but more like a completely different API on top of Node.js (or instead of Node.js).

--

[Angel Java Lopez]

Interesting thread, lot of good resources and discussion

Since my past year email, I updated my pet project, to reflect more a (very) simplified Akka system:

https://github.com/ajlopez/SimpleActors

Angel "Java" Lopez

@ajlopez

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

[Norman Paniagua]

So many new concepts here to me, and thats teach me that I'm just know almost nothing.

I would like to develop a library, only for learning purpose, I'll read those links that Tristan shares.

Angel seems very interesting your project, its also for learning purpose yet?

There is so many things that I really don't understand, one of them is how really Actors work, as far I understand basically an app have 3 elements:

- Kernel: it start the system and supervise the root actors.

- Supervisor: is an actor that supervise other actors.

- Actor: its just an actor.

Then each actor has their own route (to receive messages), but if you can talk to each actor without pass through their supervisor, what is their purpose (of the supervisor)? just know it the actor dies to restart it? or the message must pass through their supervisor before reach the destination actor? How the actor respond and to who (maybe I think much as web developer, that everything has an response and must reach the user)?

Regards 

-- 

Norman Paniagua

[Tristan Slominski]

Hey Norman,

To address some of your comments I'd like to point out some assumptions that may or may not be true.

For example, an assumption that Kernel is separate from an actor system. One of the things I've been looking at recently is to write a "kernel" in actors. But, there already exist projects which bypass the Kernel, for example the Erling (aka Erlang on Xen) has no Kernel as we "usually" think of it and boots straight into the Erlang VM (http://erlangonxen.org/). Then again, one can think of an Erlang VM as the kernel, so it's difficult to pin it down.

The Supervisor thing is really a pattern of how to set up systems made from actors. It has been demonstrated by Erlang to be a useful pattern, as you pointed out, for fault/error detection, but is not in itself a necessity to run an actor system (although, it is very useful).

As to Actors having to respond, that's also an assumption. An actor does not need to respond to any message using a request-reply pattern. Passing a message through a supervisor would not be a problem in well constructed actor systems because you'd always include a "customer" as part of the message. In Node.js you'd think of it as a callback that keeps getting passed around between calls until finally invoked. It's a continuation pattern. 

Cheers,

Tristan

[Alexey Petrushin]

> Akka system

As far as I know Akka isn't true actor framework. It offer two ways

- Actors backed by threads - simple to use, but not good for performance

- Asynchronous actors - good performance but hard to use (same async stuff, with same callback hell and other problems).

True actor - when you have both - synchronicity and performance, Akka can't provide it.

[Angel Java Lopez]

Hi people!

I don't know enough about Akka actors, Alexei. But in my pet project:

- no callback, you send a message to an actor reference, and voila

- no threads, only use the force of Node.js ;-) as usual, it leverages any async i/o processing

I don't like to refer an actor by name (including machine, tree node, etc...). I would like to refer an actor by role, or something alike. But apparently, a lot of docs/examples are available for Akka, so my first experiment is using the same ideas from Akka. Last time I see, Akka is moving to have a cluster of agents, so you don't send a message to AN agent, but to a cluster of possible duplicated agents.

More experiments (including sending message, without knowing with part will be attend the message, it is decided by configuration, not in your agent/sending module code)

http://ajlopez.wordpress.com/2013/05/30/aplicaciones-distribuidas-y-node-js/

Messaging is the key, send the message, the force it will process, Luke ;)

Angel "Java" Lopez

@ajlopez

[Tristan Slominski]

The usual problem with copying Akka design is:

var ref = system.actorFor(path);

The above line violates object capability security model (see: http://en.wikipedia.org/wiki/Object-capability_model). It's a known and admitted problem of Akka actors. It is very convenient for development, and it severely complicates any sort of security if one desires it.

Another way to think of it, that line ensures that I can have no private actors. That's an equivalent of removing private objects/variables that we tend to rely on when writing JavaScript closures. It also ensures that I have no encapsulation at actor configuration level. 

[Norman Paniagua]

I was testing different approach to implement actors:

Fork: (child_process.fork) each actor as a new process

Pros: was isolation, if the actor crash just fork it again. 

Cons: memory, each process are about 20mb.

Require: (just require every actor when needed) ie: require('./actors/my_actor')(message, callback)

Pros: memory, required about 8.7 millions and only 150mb used (just dummy actors but stored in an array so it will not be removed from memory).

Cons: maybe if an fatal error occur the entire app will crash.

Lets say then I'm happy with the "require" approach, but also I think maybe can be implemented in a mixed way (not tested yet). With maybe will have those modules:

- Kernel (part of the module): it will have the responsibility to fork a new process for every supervisor (its also an actor but will act only as supervisor) and pass the message to the corresponding supervisor

- Supervisor (part of the module): will listen the messages from the kernel and "require" each actor (when the actor finished just remove it from memory), surround by try catch the entire actor require and their callback so the supervisor not crash with the actor.

- Actor (user custom code): this will be the my custom code, process the message and send back if needed (but always call the callback method).

All of this I made only for learning, because I learn better when coding than read a lot of stuff, seems boring to me and always got distracted xD

Regards

[Norman Paniagua]

Here is on what I working... https://github.com/norman784/node-actor-test feel free to criticise it...

[Tristan Slominski]

Some things stand out in the approach so far.

The actors in the test are stateless. They do computation, but do not maintain internal state that affects follow-on communication.

Addressing the above will reveal that "require" approach is not sufficient. When you "require" a module, the module itself is a singleton, meaning that if you "require" it again, you will get the same exact one. Illustrative example:

assume foo.js contains:

var k = 0;

module.exports = {foo: k};

then in console execute:

var f = require('./foo.js');

console.log(f.foo); // prints "0"

f.foo = 7;

console.log(f.foo); // prints "7"

var g = require('./foo.js');

console.log(g.foo); // prints "7" ?!

Lastly, the identity and the "hard" part of communicating between actors via actor references is left out so far. The actor communicates to only one hard coded "next" actor sort-of by convention.

Some fundamental things to consider about actors:

Actors have internal state.

When an actor handles a message, it can *send* a finite number of messages to other actors.

When an actor handles a message, it can *create* a finite number of new actors.

When an actor handles a message, it can change it's behavior for how it will handle any follow-on messages (*become*).

I am not claiming that you cannot build useful systems without the above, but the above are a requirement for a system to be an actor system and to gain the benefits of it. To get the object capability benefits two other considerations should be taken into account:

Actor addresses are unique and unforgeable.

Actor proxies are transparent. (this basically means that if I put a man-in-the-middle actor that all it does is forward messages to some other actors and responses back to wherever, nobody is able to tell that I'm doing that)

I hope this is helpful.

Cheers

[Norman Paniagua]

Then, if understand well, Actors are like cell, in other words when the system starts all the Actors must be instantiated and will be persistent. Acts like a web, some actors just pass messages to others (proxy).

The part I don't understand well its, when the actor finished their job it calls the method (in node will be a callback) "next", where it pass a message, here I'm conceptually lost, isn't like an express app (i.e) where you just res.send(message), or maybe its so but how I build a "response" system.

Another recommendation about the fork, spawn or just require method, which you consider the best? Lets say the pros of fork / spawn will be if they do hard computation it doesn't freeze the main process, but in node it will be using a lot of ram (20mb per fork).

I'm coming from the web world so distributed computation is another world to me, so how do you structure the actors? How the system will know which actor is supervisor of which actor / groups, the only reference I see was akka and it does in the configuration.

Well maybe I need to test / read more and keep experimenting.

Regards

-- 

Norman Paniagua

[Angel Java Lopez]

Ummm... regarding:

"when the actor finished their job it calls the method (in node will be a callback) "next", where it pass a message"

AFAIK, the actor don't call a method like "next". The actor:

- receives messages

- in the process of each message *can* emit other messages to other actors

and voila!

Sometimes, the message to be processed could have the name/address of an actor, to reply-to, but it depends on what are you programming. Just reading

http://en.wikipedia.org/wiki/Actor_model

...Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created....

Angel "Java" Lopez

@ajlopez

--

[Tristan Slominski]

Then, if understand well, Actors are like cell, in other words when the system starts all the Actors must be instantiated and will be persistent. 

Not necessarily. You could have an actor configuration that starts with only one actor. You could think of that actor as a seed out of which an entire configuration of actors would grow. If your "seed" actor handles web requests, then it could *create* a new actor to handle every request that comes in. The per-request actor could then *create* more actors to handle various aspect of the request. When the request is complete, and a response is sent back to the originator of the request, every one of those actors could then be destroyed. (The abstract actor model does not talk about destroying actors much because it assumes infinite storage). 

 

The part I don't understand well its, when the actor finished their job it calls the method (in node will be a callback) "next", where it pass a message, here I'm conceptually lost, isn't like an express app (i.e) where you just res.send(message), or maybe its so but how I build a "response" system.

I guess the first step would be to highlight that the "next" callback should accept more than one message (an actor can send any finite number of messages in the process of handling one message). I would say that express app is a bad analogy/model to think of when thinking of actors. 

 

Another recommendation about the fork, spawn or just require method, which you consider the best? Lets say the pros of fork / spawn will be if they do hard computation it doesn't freeze the main process, but in node it will be using a lot of ram (20mb per fork).

The fork/spawn will not scale to millions of actors. It won't even scale well into hundreds of actors. That's a big downside. An elaboration of the require method could maybe work, but it would have to address the problem I outlined with maintaining state information.

 

I'm coming from the web world so distributed computation is another world to me, so how do you structure the actors? How the system will know which actor is supervisor of which actor / groups, the only reference I see was akka and it does in the configuration.

Another part of the actor model is how addresses become known, this sort of relates to how will actors know about one another. The usual propagation of this knowledge is encapsulated in the following "rules" of how an Actor finds out about another.

An actor can know it's own address.

An actor knows the addresses of the actors it creates directly (children).

When an actor is created, it can be given addresses of other actors (siblings).

An actor can receive an address of another actor in a message.