Let it crash

Derek posted an excellent post about Cancelling work in flight when using Akka, by introducing a Work Awaiter and Work Scheduler instead of just a Worker like many implementations do.

Vaughn Vernon—author of Implementing Domain-Driven Design—has published a very inspiring series of blog posts about actor communication patterns, in particular those described in Enterprise Integration Patterns by Hohpe & Woolf. If you have not already done so you should head over there and start reading:

• Request-Reply
• Return Address
• Envelope Wrapper
• Content Enricher
• Content Filter
• Splitter
• Content-Based Router
• Dynamic Router
• Routing Slip
• Recipient List
• Aggregator
• Scatter-Gather
• Resequencer
• Claim Check
• Message Expiration
• Message Bus
• Message Channel

This concludes the series as of this writing. Interestingly enough, the last post introduces eventsourced, the library which Martin Krasser is currently porting into the upcoming akka-persistence module as announced earlier.

Occasionally the question comes up: how do I have my actor perform a costly calculation but keep it “cancelable”. The reason for this request is usually that calculations are started in parallel and then the first successful result is used and all others discarded. But if the actor is busy processing, how do I tell it to stop?

The message-based loop shown above keeps the actor responsive by continuing “through the mailbox” from time to time. And if a StopIt message happens to have been enqueued in the meantime, all work is aborted. This shows of course only the minimalistic essence of the pattern, real use-cases will have to embed this in proper supervision hierarchies and dispatch the Work and StopIt messages through a coordinating master actor.

In this post I’m going to show a pattern that can be used to discover facts about an actor system while it is running. It can be used to understand how messages flow through the actors in the system. The main reason why I built this pattern is to understand what is going on in a running actor system that is distributed across many machines. If I can’t picture it, I can’t understand it (and I’m in good company with that quote :)

Building actor systems is fun but debugging them can be difficult, you mostly end up browsing through many log files on several machines to find out what’s going on. I’m sure you have browsed through logs and thought, “Hey, where did that message go?”, “Why did this message cause that effect” or “Why did this actor never get a message?”

This is where the Spider pattern comes in.

Keep reading

We recently needed to build a caching system in front of a slow backend system with the following requirements:

• The data in the backend system is constantly being updated so the caches need to be updated every N minutes.
• Requests to the backend system need to be throttled.

The caching system we built used Akka actors and Scala’s support for functions as first class objects.

Keep reading

Graphs have always been an interesting structure to study in both mathematics and computer science (among other fields), and have become even more interesting in the context of online social networks such as Facebook and Twitter, whose underlying network structures are nicely represented by graphs.

These graphs are typically “big”, even when sub-graphed by things such as location or school. With “big” graphs comes the desire to extract meaningful information from these graphs. In the age of multi-core CPU’s and distributed computing, concurrent processing of graphs proves to be an important topic.

Keep reading

I’ve seen a question pop up a number of times on the Akka Mailing List that looks something like: “How do you tell Akka to shut down the ActorSystem when everything’s finished?” It turns out that there’s no magical flag for this, no configuration setting, no special callback you can register for, and neither will the illustrious shutdown fairy grace your application with her glorious presence at that perfect moment. She’s just plain mean.

In this post, we’ll discuss why this is the case and provide you with a simple option for shutting down “at the right time”, as well as a not-so-simple-option for doing the exact same thing.

Keep reading

When an Actor stops, its children stop in an undefined order. Child termination is asynchronous and thus non-deterministic.

If an Actor has children that have order dependencies, then you might need to ensure a particular shutdown order of those children so that their postStop() methods get called in the right order. This pattern approaches that problem by introducing an Actor type that we’ll call a Terminator.

Keep reading