Klangism

Things that were important enough at the time when they were written.

Viktor Klang is a legendary programmer, known from places like the Internet. Consider following him on Twitter.

Nov 29

The Future is dead?

No! Long live the Future!

Something that’s new in Akka 1.0-RC1 is the possibility to add hooks that are executed when a Future is completed.

Behold!

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import akka.actor._
import akka.actor._

scala> import akka.actor.Actor._
import akka.actor.Actor._

scala> val actor = actorOf( new Actor {
  def receive = {
    case “foo” => Thread.sleep(10000); /*Simulate blocking*/
                  self.reply(“bar”)
  }
}).start

scala> (actor.!!![String](“foo”)) onComplete {
  f => println(
         if (f.result.isDefined)
           “Got result: ” + f.result.get
         else
           “Got exception: ” + f.exception.get
       )
}

11:55:33.762 [akka:event-driven:dispatcher:global-3] DEBUG akka.dispatch.MonitorableThread - Created thread akka:event-driven:dispatcher:global-3
res8: akka.dispatch.Future[String] = akka.dispatch.DefaultCompletableFuture@422f3d17

scala> Got result: bar

This also enables non-busy-waiting Futures.awaitAll, Futures.awaitOne and Futures.awaitEither!

Happy hAkking!


Nov 28

Dependency Hell

I’ve been meaning to write something very thoughtful about dependency management over the past year, but haven’t found time to do it.

So now I’ll just blurt it out and see what you think of it.

Dependency management in Java land usually means keeping track of .jar-files - this is stupid. “What?” you say?

Well packaging a .jar file means that you feel you’re qualified to make the decision on what parts of your code other people will need and use. In other words, you’re trying to see into the future and create the optimal jar for your users.

Well, wake up and smell the snow. You ain’t going to do that well.

That’s why tools like ProGuard exist - to remove superfluous code from your jars, code that isn’t needed for the program to work.

Now, wouldn’t it be nicer if things were the other way around? So instead of _removing_ what isn’t needed, you only get the classes/code you need instead?

Think about it for a second.

Then we have the current situation with Maven repositories. I hate it. It means that you have to manually keep track of tons of servers and if one is down when you need it, you either have to make sure your build works without it, or start looking for the lint in your bellybutton for a while, waiting for it to come online again.

We’ve had p2p-networks, BitTorrent and tons of different distributed storage solutions, so _why_ Dear God do we need to have manual repository management and SPOFs?

Think about it for a second.

I don’t have the technical solutions, but something where the needed classes/code would be loaded at build time and a class loader would find runtime dependencies on a distributed network at runtime and cache them locally.

Make it happen, I dare you


When you don’t handle it

Something that’s new in Akka 1.0-RC1 is the “unhandled”-callback for Actor.

This is what it looks like:

  /**
    * User overridable callback.
    *
    * Is called when a message isn’t handled by the current behavior of the actor
    * by default it throws an UnhandledMessageException
    */
    def unhandled(msg: Any){
      throw new UnhandledMessageException(msg,self)
    }


Then the current behavior of an actor doesn’t handle a message, we pass that message to the unhandled method, and by default that throws an UnhandledMessageException with the affected actor and the message that wasn’t handled. This exception doesn’t have a stacktrace (so it’s rather efficient to create).

However, this gives you an excellent opportunity to override this behavior, if you want to have DLQ or you simply want to log the unhandled message.

Enjoy!


Nov 27

The self matters

What’s new in Akka 1.0-RC1 is that HotSwap now takes the following signature:

case class HotSwap(code: ActorRef => Actor.Receive, discardOld: Boolean = true)

Before it only had:

case class HotSwap(code: Actor.Receive)

So what’s new is that you can use the “discardOld” parameter to control if you want behaviors to be stacked or not. “discardOld = true” will essentially issue an “unbecome” before it applies the new code.

The problem with HotSwap before was that you couldn’t have any reference to “self”, and that became a major pain in the rear, so we changed the signature to be a function from ActorRef to Receive, and the parameter passed to that function will be “self”.

So now you can do:

val newBehavior = (self:ActorRef) => {

  case msg => self.reply(“Service temporarily unavailable”)

}: Receive

and send it to any actor:

actorRef ! HotSwap(newBehavior)

Happy hAkking!


Oct 21

Akka 1.0-M1 is out!!

Hey!

We, the Akka committers, are very proud to announce the release of Akka 1.0-M1,
the first of 2 milestone releases leading up to the final 1.0 release.


It is all thanks to a fantastic team [http://doc.akkasource.org/team]
and user community. Thank you all for your time, hard work and great contributions.

The full release notes can be seen here: [http://doc.akkasource.org/release-notes].

91 tickets have been handled since the release of 0.10, and they can be seen here:
[https://www.assembla.com/spaces/akka/milestones/243291-1-0-milestone1]

Download it here: [http://github.com/jboner/akka/downloads].

Updated Maven repository here: [http://www.scalablesolutions.se/akka/repository/].

Here’s the documentation: [http://doc.akkasource.org]

Here’s the highlights on what’s happened since 0.10!

- Java API on par with the Scala API
- Say less, do more! Boilerplate reduction surgery performed.
- New persistence backends: Voldemort, HBase, Riak and CouchDB!
- Fewer deps for using actors only: akka-core is split into akka-actor, akka-remote and akka-typed-actor
- Lower memory footprint gives you 25% more actors on the same hardware
- ThreadBasedDispatcher can deallocate its thread when idling
- Lots of tweaks and bugfixes

Enjoy!


Oct 11

Cheaper ThreadBasedDispatchers in Akka 1.0

One of the small gems that will be available in Akka 1.0 is that ThreadBasedDispatcher is based upon ExecutorBasedEventDrivenDispatcher with a core thread pool of 1 and a max thread pool of 1 that allows core thread timeouts. This means that Actors with ThreadBasedDispatcher won’t hang on to any threads if they do not have anything to do.


Aug 19

Dispatcher configuration for Akka 0.10

Something that’s new for Akka 0.10 is the possibility to tweak the default dispatcher and the comet dispatcher in the akka.conf, this means that the operations guys can tweak the CPU usage and allows for greater possibilities to tune without recompiling.

So I thought I ought to give an explanation of the different settings possible, but first, here is what it looks like in the akka.conf


default-dispatcher {
type = "GlobalExecutorBasedEventDriven"
keep-alive-ms = 60000
core-pool-size-factor = 1.0
max-pool-size-factor = 4.0
executor-bounds = -1
allow-core-timeout = on
rejection-policy = "caller-runs"
throughput = 5
aggregate = off
}

Alright, now that’s quite a few settings, so we’d best walk through them one by one.

type is the type of the dispatcher, and the following are possible:

 
ReactorBasedSingleThreadEventDriven
ExecutorBasedEventDriven

ReactorBasedThreadPoolEventDriven
Hawt
GlobalReactorBasedSingleThreadEventDriven[1]
GlobalReactorBasedThreadPoolEventDriven[1]
GlobalExecutorBasedEventDriven[1]
GlobalHawt[1]
 
(ExecutorBasedEventDrivenWorkStealing)[2]

[1] The ones named Global* are already preconfigured, shared dispatchers, so if you specify them as the type, the other settings won’t apply.
[2] The Workstealing won’t work if you have more than one type of actor in your application, since the workstealer only can steal from the exact same actor type,


keep-alive-ms
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: Numeric in milliseconds
Does: Specifies keep alive time for threads when they are idling

core-pool-size-factor
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: Positive decimal value
Does: Specifies the factor of the number of Core Threads according to the following formula ceil(available processors * factor)

max-pool-size-factor
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: Positive decimal value
Does: Specifies the factor of the maximum number of Threads according to the following formula ceil(available processors * factor)

executor-bounds
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: -1 or a positive number
Does: Specifies whether the dispatcher is boundless (-1) or how many tasks it can handle at most at the same time.

allow-core-timeout
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: on or off
Does: Specifies whether Core Threads should also be timed out if idle

rejection-policy
Applies to: ExecutorBasedEventDriven, ReactorBasedThreadPoolEventDriven, ExecutorBasedEventDrivenWorkStealing
Value: “abort”, “caller-runs”, “discard-oldest” or “discard”
Does: Specifies what the dispatcher should do if it cannot accept a message, see this for more detailed information.

throughput
Applies to: ExecutorBasedEventDriven
Value: Positive number greater than 0
Does: Specifies how many messages the dispatcher should process for an actor before executing another actors messages.

aggregate
Applies to: Hawt
Value: on or off
Does: Specifies whether the dispatcher should aggregate messages that one actor sends to another, and send all at once when the dispatcher has finished executing for that actor.


For more documentation of what the different types of dispatchers do, check this


Happy hAkking!


Aug 17

Dining hakkers

Ladies and gentlemen,

I got inspired reading Actors all the way down so without more BS, I present to you:

Dining Hakkers implemented in Akka using the ActorModel

Can’t see the code?


Jul 18

A new era

So last friday was my last day at Yves Rocher Nordique, and it has been some very rewarding, interesting and inspiring years there. I’d like to thank my team: Jack, John, Oscar, Magnus, Kristoffer and Manne - keep being ninjas and do what’s right.

We’ve managed to pull things off no one could ever dream of, so it feels great to leave when things are going great.

But as always, when something ends something new begins, and for me that’s joining AkkaSource where I’ll be acting R&D director, so expect to see a lot of cool features appearing in both the OSS and the enterprise commercial offering.

Cheers!

/V


May 8

Akka Message Routing: Part 2

This is the second part of the akka message routing miniseries.

This time I’m going to show you how to create a message loadbalancer,

so without further ado:

Can’t see the code?

That wasn’t hard was it?

Now, go experiment and perhaps create your own message distribution algorithms, there’s already one that dispatches depending on target mailbox size, effectively dispatching to the one that’s got fewest messages to process right now.