Jumi Actors 0.1.64 released

[Esko Luontola]

Though Jumi itself is not yet ready for use, its actors library is quite
mature and has now been released. You may read more about it at
http://jumi.fi/actors.html

Next I'll be working on getting the first technology preview of Jumi
released. There are a couple of critical features that I will implement
first:

- Proper test runner process startup and shutdown. That area of the code
is the last remains of the walking skeleton from the beginning of this
project, so I will need to refactor it up to production quality.

- Test class discovery. Until now Jumi has supported only running one
test class at a time, so I'll implement support for finding all test
classes using a file name pattern.

- Showing what text tests print to stdout and stderr. Helpful in
debugging tests when just the stack trace is not enough. This will be
Jumi's first differentiating feature compared to other test runners
which rely on reading the stdout and stderr of an external process. Jumi
will collect the output by hooking into System.out/err, which lets it
show precicely that which test printed what text.

Once these and a couple of other improvements are in place, I will
release Jumi's technology preview. There won't yet be any IDE or build
tool integration, so running the tests will be chore, but that will
improve with the following releases.

I'll migrate my testing framework Specsy (http://specsy.org/) to use
Jumi (and port it to Scala, Groovy and Java), create a JUnit backward
compatibility adapter (restricted to class-level parallelism), and hint
some other testing framework developers that they should write Jumi
drivers for their frameworks (e.g. Scala's specs/specs2 and ScalaTest).

--
Esko Luontola
www.orfjackal.net

[deakblue]

So I have given your actors framework a whirl, and I'm very pleased with the results.  I'm very new to this kind of programming, but I found it very easy to understand and employ.

I believe that the application I'm developing fits well with an actor model, but if you're willing, I could use some feedback both generally and with respect to jumi.

I'm developing a long running service that must listen and emit messages over multiple sockets.  The transport varies, so in some cases I'm listening for a ZMQ message, a UDP broadcast, or the result of a long poll HTTP request.   Similarly, I'm emitting messages asynchonously on other sockets.   To simplify this, one could imagine a chat server that listens to multiple sockets, changes the state of a conversation within a 'room' and rebroadcasts the updated shared state.

What I've tried, successfully so far, is wrapping my listeners in actors.  They receive messages and pass them to a room, subscribers to the room are themselves actors who unicast or broadcast updates.  Although the app is significantly more complicated than a simple chat server, the basic relationships can basically be boiled down to actors for listening, actors for rooms, actors for proxying subscribers.

As I'm writing this, I ran across http://doc.akka.io/docs/akka/1.3.1/scala/tutorial-chat-server.html in Akka.  It seems to correspond roughly with how I'm attacking it. 

So my questions:

1. any comments on the game plan?  As you can see, the concurrency I'm after is more task oriented as opposed to performance motivated, but I think it's compatible, maybe?

2. Multiple interfaces and Jumi:  If I understand correctly, jumi will queue inbound messages so that the actor is protected from processing two calls simultaneously.  I believe this also stands if the inbound calls are on different interfaces, yes?

3. I'm not sure about logging, but it sounds like you have something cooked up for monitoring the message passing?  Is this true? Example?

Anyway, not looking for you to do my homework, but if this is a good fit, it might be attractive to other devs with similar problems.

Thanks for an exciting framework,

-Will

[Esko Luontola]

On Thursday, 4 October 2012 22:54:05 UTC+3, deakblue wrote:

So I have given your actors framework a whirl, and I'm very pleased with the results.

I'm glad you like it.

 

So my questions:

1. any comments on the game plan?  As you can see, the concurrency I'm after is more task oriented as opposed to performance motivated, but I think it's compatible, maybe?

Looks good. An event-driven design should fit an application like that.

 

2. Multiple interfaces and Jumi:  If I understand correctly, jumi will queue inbound messages so that the actor is protected from processing two calls simultaneously.  I believe this also stands if the inbound calls are on different interfaces, yes?

Yes, all actor interfaces which are bound to the same ActorThread are processed in the same thread. The simplest way to structure a program with Jumi Actors is to have only one ActorThread, so that the whole program is single-threaded. Since your program doesn't appear to need multiple threads for performance reasons, having just one thread should be enough.

3. I'm not sure about logging, but it sounds like you have something cooked up for monitoring the message passing?  Is this true? Example?

You can do monitoring by giving the actors container's constructor a MessageListener such as PrintStreamMessageLogger [1]. In the future I might extract an abstract base class from PrintStreamMessageLogger, to make it easier to create new MessageListener implementations, but for now your best bet is to copy PrintStreamMessageLogger and modify it to your needs.

[1] https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/main/java/fi/jumi/actors/listeners/PrintStreamMessageLogger.java

[deakblue]

Thanks, I've been mulling over your response...

Yes, all actor interfaces which are bound to the same ActorThread are processed in the same thread. The simplest way to structure a program with Jumi Actors is to have only one ActorThread, so that the whole program is single-threaded. Since your program doesn't appear to need multiple threads for performance reasons, having just one thread should be enough.

If the actor blocks or dies while answering a call, is that on me, or is there a Jumi approach to resiliency?

Thanks again,

-Will

[Esko Luontola]

deakblue wrote on 9.10.2012 20:43:
> If the actor blocks or dies while answering a call, is that on me, or is
> there a Jumi approach to resiliency?

If an actor blocks, then nothing else is executed on the same actor
thread, so it's better to avoid blocking actors or to put them into
their own actor threads. If an actor throws an exception, then the
exception is passed to the FailureHandler of the actor container. The
FailureHandler may stop the actor thread immediately (by interrupting
the current thread) or let it continue processing messages.

Jumi Actors doesn't provide anything else for resiliency than what a
FailureHandler can do. I think this is one of the biggest differences
compared to Akka, but it also keeps Jumi Actors simple.

Jumi Actors was designed for the needs of the Jumi test runner, where
it's enough to have process-level resiliency - if things fail, I can
just restart the whole process. Actually that's a feasible strategy also
for high-availability systems: http://lwn.net/Articles/191059/

--
Esko Luontola
www.orfjackal.net

[deakblue]

This is reasonable, just wanted to clarify.

In fact, I'm using Jumi because it's minimal.  What I believe I get from Jumi is a thin actor wrapper around POJOs.  After working with Akka for a little while, I wanted something lighter.  I'm looking to use Jumi on Android and I can do so without having to strip binaries or other contortions.

I think that gets to all my initial questions.

Good luck with Jumi Test Runner,

-Will