In-Depth Introduction

The Actor Model itself is pretty simple, but it's the way that it frames the problem that creates big advantages. A program's code is divided into multiple different parts and each part runs as an Actor. Each Actor has an address, and Actors can exchange messages by sending a message to another Actor's address. Actors do not share state (i.e. memory), but they may maintain their own internal state.

Each Actor basically just hangs out until it gets a message. When it gets a message, it does one of three things:

1. sends a finite number of messages
2. creates a finite number of other Actors
3. updates internal state

At first glance, that sounds pretty trivial, but the power of the Actor Model lies more in what is not described above: Actors do not have to spend time managing their environment, establishing and maintaining a communications framework to each other; there are no locks, semaphores, or other complex concurrency concerns. All of these things are handled by the Actor System (the framework in which the Actors run), and the Actors are freed to focus on the main concerns of the application.

This external component, the Actor System, is the place where all of these mundane issues are handled. There are several different Actor System implementations available in different languages (e.g. Akka for Scala or Java, Thespian for Python). Although they differ somewhat in various details, they all provide a common set of features, including:

• Creating the actual Actor instances
• Handling message delivery from one Actor to another
• Managing Actor lifecycles
• Providing appropriate scheduling and concurrency between different Actors.

One of the first things you'll notice when writing Actor-based code is how easy it is to write code for.

Environment

While it is possible to provide configuration information to customize your setup, it is often not necessary to specify anything for a simple environment.

Code

Actors don't need lots of setup code and management. With many libraries, you simply include a module, subclass a base Actor object to define the Actor code, then create the Actor in a single library call.

To demonstrate how easy this is, let's look at an example using the Thespian Python Actor library.

In the Hello World example above, only a single Actor was created and used. It's actually possible to create any number of Actors (subject to system limits), and for Actors to create other Actors.

 1: from thespian.actors import *
 2: 
 3: class Hello(Actor):
 4:     def receiveMessage(self, message, sender):
 5:         if message == 'are you there?':
 6:             world = self.createActor(World)
 7:             worldmsg = (sender, 'Hello,')
 8:             self.send(world, worldmsg)
 9: 
10: class World(Actor):
11:     def receiveMessage(self, message, sender):
12:         if isinstance(message, tuple):
13:             orig_sender, pre_world = message
14:             self.send(orig_sender, pre_world + ' world!')
15: 
16: class Goodbye(Actor):
17:     def receiveMessage(self, message, sender):
18:         self.send(sender, 'Goodbye')
19: 
20: def run_example(systembase=None):
21:     hello = ActorSystem(systembase).createActor(Hello)
22:     goodbye = ActorSystem().createActor(Goodbye)
23:     greeting = ActorSystem().ask(hello, 'are you there?', 1.5)
24:     print(greeting + '\n' + ActorSystem().ask(goodbye, None, 0.1))
25:     ActorSystem().shutdown()
26: 
27: if __name__ == "__main__":
28:     import sys
29:     run_example(sys.argv[1] if len(sys.argv) > 1 else None)

The above runs as follows:

$ python hellogoodbye.py
Hello World!
Goodbye

In the hellogoodbye example, the Hello Actor does not send a message directly back to the sender, but instead passes the sender's address to another Actor that it creates on the fly (in line 6). The second Actor (World) receives a tuple which is the combination of the original sender's address and the first part of the message (created in line 7). The World Actor updates the message and then sends the resulting message to the original sender (line 14).

The main code (outside the Actor System) has also created another Actor (the Goodbye Actor). The message printed to the console in line 24 is the result of calling both the Hello and the Goodbye Actors (and indirectly the World Actor).

title Hello Goodbye Sequence Diagram
create Main
create Hello
Main ->> Hello: createActor()
create Goodbye
Main ->> Goodbye: createActor()
Main ->> Hello: ask()
activate Hello
create World
Hello ->> World: createActor()
Hello ->> World: send()
deactivate Hello
activate World
World -->> Main: send()
deactivate World
Main ->> Goodbye: ask()
activate Goodbye
Goodbye -->> Main: send()
deactivate Goodbye

Each time the Hello Actor is called, it will create a new Actor. If Hello were sent too many messages, the system would eventually fail because too many World Actors had been created. To avoid this unconstrained growth, there are two options:

1. Hello only creates one World Actor and remembers the address:

            if not hasattr(self, 'world'):
                self.world = self.createActor(World)
            self.send(self.world, (sender, 'Hello'))
   

2. The World Actor exits after doing its work. An Actor will exit if it receives an ActorExitRequest message (this message is defined in the thespian import file). The ActorExitRequest message can be sent by any Actor to any other Actor, so the Hello Actor could send it as follows:

            world = self.createActor(World)
            self.send(world, (sender, 'Hello,'))
            self.send(world, ActorExitRequest())
   

   Because the ActorExitRequest is sent just like any other message, the World Actor could send it to itself (using the myAddress self-reference provided by the Actor base class):

            orig_sender, pre_world = message
            self.send(orig_sender, pre_world + ' world!')
            self.send(self.myAddress, ActorExitRequest())
   

When the Actor System delivers an ActorExitRequest to an Actor, it will pass that message to the Actor's receiveMessage() method to allow the Actor to perform shutdown activities. Once the receiveMessage() returns from handling the ActorExitRequest, the Actor System will destroy the Actor. If the Actor does not need to do any operations prior to being destroyed, it is free to ignore the ActorExitRequest message, but the if statement in line 12 ensures that when the World Actor receives the ActorExitRequest it does not try to interpret it as the greeting message it expected from the Hello Actor.

Whenever an Actor exits, the Actor that initially created it will be notified via a ChildActorExited message. This message is generated by the Actor System and specifies the address of the Actor which exited. This is why there is also an if statement in line 5 above: when the World Actor exits the Hello Actor should not create another World Actor and send it a message—this would result in an infinite loop!

There are other messages that can be delivered to an Actor by the Actor System (all derived from the ActorSystemMessage base class); these will be described in later parts of this article. Any Actor is free to ignore any of the messages delivered by the Actor System: they are designed to allow for additional functionality (e.g. restarting Actors that have exited) but only if that functionality is needed or desired.

The ActorSystem Base determines how the Actor System implements the Actor concurrency and transport elements for supporting the Actors. There can be bases for implementing Actors as separate processes, or separate threads, or simply sequential execution. There can be system bases that use UDP to communicate between Actors and system bases that use TCP, bases that use a message bus, etc.

The choice of system base can be made almost completely independently of the Actor code, which allows for significant upgrade and operational implementation flexibility. The Actor System represents a higher level of abstraction than other models (e.g. a message bus "pub/sub" architecture) which helps decouple the Actor internal logic from the transport and concurrency issues. An Actor-based application could be implemented with an Actor System running on top of a pub/sub transport, but if the pub/sub transport needed to be changed to a different transport this could be done by simply changing the system base and there would be no impact on the Actors themselves.

The primary argument to the first ActorSystem() call specifies which system base to use (recall that ActorSystem() is a singleton, so it's only necessary to pass any initialization arguments to the very first call). Different "bases" provide different Actor System-level functionality; they do not change the way that Actors work but they change the way that they are implemented. The Using Thespian guide defines the set of available system bases available for Thespian.

By default, the "simpleSystemBase" is used, which runs all Actors synchronously in the current process. While this base is very useful for debugging (see the Debugging section), it does not provide the level of concurrency usually desired at production time.

To demonstrate the use of different ActorSystem bases, the Actor System shutdown() method call in line 25 of hellogoodbye.py above can be commented out, and different bases can be specified on the command line. In the following example the "multiprocTCPBase" is used; this system base implements Actors with multiprocess concurrency and uses TCP as the transport:

$ python hellogoodbye.py multiprocTCPBase
$ ps -eafw | grep -i [a]ctorad
...
kquick 5596 5594  0 21:51 pts/86  00:00:00 __main__.Hello ActorAddr-(TCP|10.56.10.5:35862)
kquick 5597 5594  0 21:51 pts/86  00:00:00 World ActorAddr-(TCP|10.56.10.5:46023)
kquick 5598 5594  0 21:51 pts/86  00:00:00 __main__.Goodbye ActorAddr-(TCP|10.56.10.5:59137)
...

Assuming you have the setproctitle package installed, the ps listing above shows a number of processes, including a Hello Actor process, a World Actor process, and a Goodbye Actor process. Each ps entry shows the Address of each Actor (including the TCP IP address and port number).

Re-running this test with the "multiprocUDPBase" which implements Actors as separate processes but uses UDP as the transport we can see additional Actors have been created with different Actor addresses:

$ python hellogoodbye.py multiprocTCPBase
$ ps -eafw | grep -i [a]ctorad
...
kquick 5596 5594  0 21:51 pts/86  00:00:00 __main__.Hello ActorAddr-(TCP|10.56.10.5:35862)
kquick 5597 5594  0 21:51 pts/86  00:00:00 World ActorAddr-(TCP|10.56.10.5:46023)
kquick 5598 5594  0 21:51 pts/86  00:00:00 __main__.Goodbye ActorAddr-(TCP|10.56.10.5:59137)
kquick 7446 7444  0 21:57 pts/86  00:00:00 __main__.Hello ActorAddr-(UDP|10.56.10.5:37643)
kquick 7447 7444  0 21:57 pts/86  00:00:00 World ActorAddr-(UDP|10.56.10.5:45316)
kquick 7448 7444  0 21:57 pts/86  00:00:00 __main__.Goodbye ActorAddr-(UDP|10.56.10.5:51954)
...

In this output we can see the previous TCP transport-based Actors are still present, but now there are a set of UDP transport-based Actors as well.

Part of the output elided in the above examples contained entries like the following:

...
kquick 5594    1  0 21:51 pts/86  00:00:00 MultiProcAdmin ActorAddr-(TCP|10.56.10.5:1900)
kquick 5595 5594  0 21:51 pts/86  00:00:00 logger ActorAddr-(TCP|10.56.10.5:51866)
...

These processes are specific to the multiprocTCPBase system base (there are an equivalent pair for the multiprocUDPBase). The MultiProcAdmin represents the "Actor System" itself and is responsible for coordinating the Actor process creation and deletion and message delivery responsibilities of the Actor System. The logger provides coordinated use of the python standard logging facility for all of the Actors managed by that Actor System (an optional argument to the Actor System can specify the logging facility configuration).

Each time the above tests are run, a new set of Hello, World, and Goodbye Actors are created. Feel free to play around, and when you want all of them to be deleted, simply uncomment the Actor System shutdown() call in line 25 above and run it one last time: although new Actors are created each time, each run will automatically connect to the existing Admin for that system base, so shutting down that Admin will stop all Actors in that Actor System.

As mentioned above, the Using Thespian document provides much more detail about the available System Bases for Thespian and their capabilities. Other Actor System implemntations may or may not have similar configurability.

Thespian supports the standard logging library, but provides some enhanced handling of log messages to accomodate the different system bases that may implement Actors in separate processes (or even on separate systems): as described in the Logging section of the Using Thespian documentation, log messages are forwarded to a "Logging" process to be written according to the logging configuration supplied when the ActorSystem() initialization call was made. In addition, for multi-system configurations, any messages of Warning level or higher are forwarded to the Convention Leader for logging there as well.

Here is the helloworld example again, but with a logging statement inserted in one of the actors:

 1: import logging
 2: from thespian.actors import *
 3: 
 4: class Hello(Actor):
 5:     def receiveMessage(self, message, sender):
 6:         logging.info('Hello actor got: %s', message)
 7:         if message == 'are you there?':
 8:             world = self.createActor(World)
 9:             worldmsg = (sender, 'Hello,')
10:             self.send(world, worldmsg)
11: 
12: class World(Actor):
13:     def receiveMessage(self, message, sender):
14:         if isinstance(message, tuple):
15:             orig_sender, pre_world = message
16:             self.send(orig_sender, pre_world + ' world!')
17: 
18: class Goodbye(Actor):
19:     def receiveMessage(self, message, sender):
20:         self.send(sender, 'Goodbye')
21: 
22: def run_example(systembase=None):
23:     hello = ActorSystem(systembase).createActor(Hello)
24:     goodbye = ActorSystem().createActor(Goodbye)
25:     greeting = ActorSystem().ask(hello, 'are you there?', 1.5)
26:     print(greeting + '\n' + ActorSystem().ask(goodbye, None, 0.1))
27:     ActorSystem().shutdown()
28: 
29: if __name__ == "__main__":
30:     import sys
31:     run_example(sys.argv[1] if len(sys.argv) > 1 else None)

When this is run, the following output is obtained:

$ python hellogoodbyelog.py multiprocTCPBase
INFO: Thespian.Admin:ActorSystem Administrator startup @ ActorAddr-(TCP|12.34.56.78:1900)
INFO:root:Hello actor got: are you there?
Hello, world!
Goodbye
INFO:root:Hello got: ActorExitRequest
INFO:root:Hello got: ChildActorExited:ActorAddr-(TCP|12.34.56.78:47034)

The logging statement on line 6 has generated the INFO statements (except for the first which came from the Thespian ActorSystem itself) in the output above because the default logging configuration is to write to the console.

To customize the logging (for example, to write to a file called hello.log), pass the logging configuration dictionary to the ActorSystem() call as the logDefs argument.

 1: import logging
 2: from thespian.actors import *
 3: 
 4: class Hello(Actor):
 5:     def receiveMessage(self, message, sender):
 6:         logging.info('Hello actor got: %s', message)
 7:         if message == 'are you there?':
 8:             world = self.createActor(World)
 9:             worldmsg = (sender, 'Hello,')
10:             self.send(world, worldmsg)
11: 
12: class World(Actor):
13:     def receiveMessage(self, message, sender):
14:         if isinstance(message, tuple):
15:             orig_sender, pre_world = message
16:             self.send(orig_sender, pre_world + ' world!')
17: 
18: class Goodbye(Actor):
19:     def receiveMessage(self, message, sender):
20:         self.send(sender, 'Goodbye')
21: 
22: logcfg = { 'version': 1,
23:            'formatters': {
24:                'normal': {
25:                    'format': '%(levelname)-8s %(message)s'}},
26:            'handlers': {
27:                'h': {'class': 'logging.FileHandler',
28:                      'filename': 'hello.log',
29:                      'formatter': 'normal',
30:                      'level': logging.INFO}},
31:            'loggers' : {
32:                '': {'handlers': ['h'], 'level': logging.DEBUG}}
33:          }
34: 
35: def run_example(systembase=None):
36:     hello = ActorSystem(systembase, logDefs=logcfg).createActor(Hello)
37:     goodbye = ActorSystem().createActor(Goodbye)
38:     greeting = ActorSystem().ask(hello, 'are you there?', 1.5)
39:     print(greeting + '\n' + ActorSystem().ask(goodbye, None, 0.1))
40:     ActorSystem().shutdown()
41: 
42: if __name__ == "__main__":
43:     import sys
44:     run_example(sys.argv[1] if len(sys.argv) > 1 else None)

In line 36 above, the logDefs argument specifies the logging configuration defined at line 22. Running this version of the code yields the following:

$ python hellogoodbyelog2.py multiprocTCPBase
Hello, world!
Goodbye
$ cat hello.log
INFO     Hello actor got: are you there?
INFO     Hello actor got: ActorExitRequest
INFO     Hello actor got: ChildActorExited:ActorAddr-(TCP|12.34.56.78:52790)
$

Note that in the above examples, the multiprocTCPBase is used. If the default simpleSystemBase is used no logging output appears for the first example (where no logDefs argument was specified). This is because the default logging level for the simpleSystemBase is set to logging.WARNING; the second example uses specific logging configuration which overrides the default.

In the examples shown above, messages were delivered to the different Actors and those Actors processed those messages. One of the important things to note is that each call to an Actor's send() method is asynchronous: there is no guarantee that the target Actor has received—or processed—the message by the time the send() method returns.

Because Actors do not share state (memory), this asynchronous send makes no difference to their implementation. It is the responsibility of the Actor System to perform the scheduling of each Actor, invoking its receiveMessage() to handle the delivered message. There are two primary constraints on Actor message handling:

1. Each Actor will only process one message at a time. It must return from the receiveMessage() handling of the current message before the next message will be delivered to the Actor.
2. Thespian guarantees that messages sent from Actor A to Actor B are delivered to B in the same order that they are sent by A, but if Actor C is also sending messages to Actor B there is no guarantee that A's messages and C's messages will not be commingled.

Actors thus operate on individual messages, running when a message is received and finishing when they exit from the receiveMessage(), during which they may have created other Actors or sent other messages. This message passing paradigm is different from the conventional blocking paradigm used by most code. In Thespian, there are no need for special objects like futures that hide asynchronous functionality behind what looks like synchronous code. If an Actor does block during the receiveMessage() execution, it will not receive other messages while it is blocked; the typical method of addressing this in an Actor model is to start up more Actors or delegate the blocking functionality to a sub-Actor that was dynamically created as needed.

This obliviousness of the Actors to the underlying concurrency and scheduling implementation is a very powerful abstraction. This means that the concurrency is completely determined by the Actor System itself, and that the concurrency can be changed by the Actor System without impacting the Actor code itself at all.

For example, depending on the ActorSystem Base selected, Thespian could implement each Actor as a separate thread running in the current process. The next time the application was started, it could use an Actor System that implemented each Actor as a separate process instead of a thread—as simply as that. This allows another vector of scalability for the application: it is not necessary to choose which concurrency method to use (threads, processes, pools of either, greenlets, etc.) when writing the application's core logic: simply start with an Actor System implementing one and switch to a different Actor System if a different concurrency type is needed later on.

When an Actor wishes to send a message to another Actor, it uses the self.send() method and specifies the Address of the target Actor. That Address cannot be generated by the sending Actor: it must have been given to the Actor as the result of a self.createActor() call or in the body of a message passed to it's receiveMessage() method.

Actors must treat the Address of another Actor as an opaque object; the actual information in the Address is determined and used by the currently running Actor System, and it may change between runs of the Actor application.

One advantage of this opaqueness of Addresses, and also of not having shared state is that Actors have no direct interaction with each other: they only interact via asynchronous message delivery. This means that the sending Actor doesn't know or care where the target Actor is: a thread in the same process, another process on the current host node, another host node in the same datacenter, or a host node halfway around the world. This is known as location independence and means that the Actors operate independently of their relative locations. This allows Actors to be distributed throughout the available environment as appropriate… again without any changes to the Actor application code itself.

The combination of location independence and Horizontal Scalability means that Actor-based applications are particularly well suited to cloud-based solutions where changes in the relative size of the cloud deployment can be realized through duplicating, moving, or de-duplicating Actors.

Any modern application must be capable of dealing with faults, and this is definitely true of a distributed system which has by its very nature many additional places where faults can occur. The same benefits that make Actors easy to use with Location Independence also make them resilient to Faults in the system.

Because Actors do not share state and only communicate via message passing, the failure of an Actor does not directly affect any of the other Actors running in the system. The Actor System itself will be aware of the Actor failure and can take corrective action but the other Actors in the system are oblivious (unless they choose otherwise).

When an Actor fails, the Actor System will respond to that failure:

• The Actor System will restart the Actor and re-deliver the message that it was processing when it failed (all other inbound and outbound messages for that Actor are unaffected).
• If the Actor fails again processing the same message, the Actor System determines that it is the message that is causing the problem.
  • The Actor System will restart the Actor yet again, but it will not deliver that same message to the Actor.
  • The Actor System will wrap the message in a PoisonMessage wrapper and send it back to the Actor which originally sent the message. This originating Actor is free to ignore this PoisonMessage, or it can provide operational recovery handling.
  • The failed Actor will resume processing messages with the next message to be delivered.

Clearly the application logic embedded within the Actors must decide whether or not action should be taken on the PoisonMessage as determined by the overall funcationality of the application. The advantage provided by the Actor Model is that the default mode of operation is to preserve the functionality of the application as a whole and to localize the impact of that failure. This is in marked contrast with monolithic applications, where by default an exception will cause the termination of the entire application and even caught exceptions can still be significantly disruptive, including interfering with concurrency.

For security purposes, there is a special Actor that can register itself as the "Source Authority". Any loaded image is passed to the Source Authority for validation before it is useable for createActor() operations. The Source Authority can perform whatever validation it chooses on the loaded image (e.g. validating a signature); images which are not approved by the Source Authority are rejected and cannot be used.

For the example in the section below, the following script is run first to startup an actor system and load a Source Authority that will accept any loaded sources.

 1: from thespian.actors import ActorSystem, Actor, ValidateSource, ValidatedSource
 2: import sys
 3: 
 4: class SimpleSourceAuthority(Actor):
 5:     def receiveMessage(self, msg, sender):
 6:         if msg is True:
 7:             self.registerSourceAuthority()
 8:         if isinstance(msg, ValidateSource):
 9:             self.send(sender,
10:                       ValidatedSource(msg.sourceHash,
11:                                       msg.sourceData,
12:                                       # Thespian pre 3.2.0 has no sourceInfo
13:                                       getattr(msg, 'sourceInfo', None)))
14: 
15: 
16: if __name__ == "__main__":
17:     if "shutdown" in sys.argv:
18:         ActorSystem('multiprocTCPBase').shutdown()
19:         sys.exit(0)
20:     asys = ActorSystem('multiprocTCPBase')
21:     sa = asys.createActor(SimpleSourceAuthority)
22:     asys.tell(sa, True)

Because the Thespian Actor Systems communicate as part of a Convention, the source image only needs to be loaded on the Convention Leader system. When the createActor() is called and the capabilities require the Actor to be created remotely, the remote Actor System is told the Actor and the source image hash. If the remote Actor System does not have that hashed source image available already, it will request it from the Convention Leader and then use it to fulfill the Actor creation request.

There is no limit to the number of currently loaded active sources (other than available system memory) and the loaded sources function independently of each other. Multiple instances of the same application can be loaded, as well as multiple different applications sharing the same Actor System.

The previous Hello example can now be updated to use loadActorSource() to ensure that the latest version of the source is used each time it is run:

 1: from thespian.actors import *
 2: 
 3: class Hello(Actor):
 4:     def receiveMessage(self, message, sender):
 5:         self.send(sender, 'Hello, world!')
 6: 
 7: def zipMyself():
 8:     zipname = 'hi.zip'
 9:     import zipfile
10:     zf = zipfile.ZipFile(zipname, 'w')
11:     zf.writestr('hi.py', open('hi.py', 'r').read())
12:     zf.close()
13:     return zipname
14: 
15: def say_hello():
16:     actorSys = ActorSystem("multiprocTCPBase")
17:     loadHash = actorSys.loadActorSource(zipMyself())
18:     hello = actorSys.createActor('hi.Hello',
19:                                  sourceHash = loadHash)
20:     print(actorSys.ask(hello, 'are you there?', 1.5))
21:     actorSys.tell(hello, ActorExitRequest)
22: 
23: if __name__ == "__main__":
24:     say_hello()

This example creates the zipfile from itself (with a couple of assumptions… this is just an example) although normally you would distribute your code as a zipfile generated by $ python setup.py sdist or something similar.

The zipfile is loaded into the currently running Actor System in line 17 and then the creation of the Actor in line 19 uses the hash value obtained from loading the source to specify which source the Actor should be created from. Note also that the Actor to be created is referred to by name instead of by reference, and that name is qualified by the zipfile name to match standard Python import semantics.

Running this and changing the source in between runs clearly shows that the changes are loaded and used in subsequent runs:

$ python runsys.py
$ python hi.py
Hello, world!
$ python hi.py
Hello, world!
$ edit hi.py  # <-- change "world" to "universe"
$ python hi.py
Hello, universe!
$ python runsys.py shutdown

The sources loaded remain loaded until unloaded via a call to unloadActorSource() or until the Actor System exits.

At startup, the start command should be used to specify which Actor System base and parameters should be used. This command internally generates an ActorSystem() API call, so it will either create an Actor System or connect to an existing persistent Actor System.

At that point, commands may be typed, including the ability to send simple string messages to Actors. The help command can be used to obtain more information, and the exit or quit commands can be used to leave the shell.

$ python -m thespian.shell
thespian> start multiprocTCPBase
Starting multiprocTCPBase ActorSystem
thespian> exit
$

The thespian shell provides special handling for Actor Addresses. Rather than being required to type the full Actor Address each time, the shell provides the address command which can be used to "register" an Actor Address. Each registered address is assigned an index, which is always shown in square brackets following the address itself. All other commands use this index to refer to a specific address.

$ python -m thespian.shell
thespian> start multiprocTCPBase
Starting multiprocTCPBase ActorSystem
thespian> address localhost 1900
Actor Address 0: ActorAddr-(TCP|127.0.0.1:1900)
thespian> 

There is also a test Actor that is part of the shell. The test Actor simply sends back anything it gets with a message that it received it, unless the message is the string "create", in which it will create another TestActor and return the address of that Actor.

$ python -m thespian.shell
thespian> start multiprocTCPBase
Starting multiprocTCPBase ActorSystem
thespian> create_testActor
Created new TestActor 0 @ ActorAddr-(TCP|10.56.10.5:46883)
thespian> ask 0 hello
Response: TestActor @ ActorAddr-(TCP|10.56.10.5:46883) got: hello
thespian> ask 0 create
Response: ActorAddr-(TCP|10.56.10.5:54991)
thespian> address 10.56.10.5:54991
Actor Address 1: ActorAddr-(TCP|10.56.10.5:54991)
thespian> ask 1 hi
Response: TestActor @ ActorAddr-(TCP|10.56.10.5:54991) got: hi

The shell also supports issuing status queries to Actors. The status query returns various information about the Actor.

thespian> status 0
Requesting status from Actor (or Admin) @ ActorAddr-(TCP|127.0.0.1:1900) (#0)
Status of ActorSystem @ ActorAddr-(TCP|10.56.10.5:1900) [#1]:
  |Capabilities[5]:
        Thespian ActorSystem Name: multiprocTCPBase
     Thespian ActorSystem Version: 1
                 Thespian Version: 1441577971430
                   Python Version: (2, 6, 9, 'final', 0)
              Thespian Generation: (2, 1)
  |Convention Attendees [0]:
  |Primary Actors [2]:
    @ ActorAddr-(TCP|10.56.10.5:51966) [#2]
    @ ActorAddr-(TCP|10.56.10.5:48095) [#3]
  |Rate Governer: Rate limit: 4480 messages/sec (currently low with 33 ticks)
  |Pending Messages [0]:
  |Received Messages [0]:
  |Pending Wakeups [0]:
  |Pending Address Resolution [0]:
  |>               Actor.Message Send.Transmit Started: 33
  |>                      Admin Message Received.Total: 54
  |>           Admin Message Received.Type.Dead Letter: 1
  |> Admin Message Received.Type.Pending Actor Request: 10
  |>           Admin Message Received.Type.QueryExists: 22
  |>             Admin Message Received.Type.StatusReq: 1
  |DeadLetter Addresses [0]:
  |Source Authority: None
  |Loaded Sources [2]:
    f63171ffe80778e5a4f07203f41ce021
    cbc67614f8792ecf3504772d793905b4
  |Global Actors [0]:
thespian>

The status information may change over time and should not be programmatically relied upon at this time.