Klangism

Serializable dynamic Proxies

Wed, 23 Nov 2011 15:36:13 +0100

So, I found myself in a situation where I was creating JDK Proxies, and I was in control of the invocation of newProxyInstance and needed to make the Proxies transparently Serializable.

The problem is that for it to work you need writeReplace, so that you’re in control of the rematerialization of the Proxy on the deserializing side using readResolve.

However, the problem is that you need to make sure that the Proxy gets a writeReplace method, and you don’t want to force the guy providing you with what interfaces to proxy to implement writeReplace himself, because at some point someone will forget it.

The solution might seem trivial, but the solution is the following:

Define a trait/interface with the writeReplace method (with correct signature)

Happy hAkking!

Cheers, √

DIY: Exhaustiveness checking on Scala Enums

Fri, 01 Jul 2011 01:16:00 +0200

Long time no blog,

I’m not much of a writer, so here’s the code!

Hardlink

Cheers,

√

Implementing PostStart in #Akka

Sun, 06 Mar 2011 00:14:00 +0100

This question comes up every now and then, and my answer has since the first time, been refined, so I thought I’d give the answer here.

“How do I run some initialization logic in the thread of the dispatcher and not the creator of the actor?”

I present to you, PostStart:

If you can’t see the code, click here

Easy?

Enjoy!

This is exactly what I want Akka to solve

Fri, 25 Feb 2011 10:59:50 +0100

“The fact is that everyone has scalability issues, no one can deal with their service going from zero to a few million users without revisiting almost every aspect of their design and architecture.”

Quoted from : http://37signals.com/svn/archives2/dont_scale_99999_uptime_is_for_walmart.php

All #Actors in #Scala - compared

Tue, 28 Dec 2010 13:56:00 +0100

As a late Christmas present I bring this to you dear readers:

I recently invited David Pollak (of Lift fame), Jason Zaugg (of Scalaz fame), Philipp Haller (of Scala Actors fame) and myself to collaborate on a feature matrix that would allow people to see the similarities and differences between the Actor libraries on the Scala platform.

So I’d like to start out by thanking David, Jason, Runar, Jonas, Philipp, Martin and all the people involved in these great projects for taking the time to fill out the matrix.

Here’s a link to a PDF-version of the document, enjoy!

PS. I attempted to embed the comparison to this blog post, but the formatting simply goes haywire. DS.

√iktor needs your help!

Mon, 27 Dec 2010 16:03:52 +0100

I’ve got some ideas for conference/group talks that I have yet to assemble, but I thought I’d let the community have a vote in what they’d think be interesting.

Proposal 1:

Git things done

Approx time: 45 minutes

“This is a case-study on moving from CVS/SVN to Git I did at a previous employer. It’s about the challenges faced - cultural problems, technical problems, process problems and touches areas like: Code reviews, agile&lean (Scrum/Kanban), pragmatisism and corporate politics.”

Proposal 2:

The Kay Way - True Object Orientation

Approx time: 30 minutes

“This talk explores OO using Actors, a model of concurrency that encapsulates Alan Kays original concept of object-orientation, showing different models of composition and inheritance, message-passing, asynchronous and synchronous messaging using the Akka framework”

Proposal 3:

Faster, Harder, Actor

Approx time: 25 minutes

“At the very core of Akka lies the Executor-Based-Event-Driven-Dispatcher, or EBEDD as we call it for short. This talk goes through its design and how it manages to provide the best default for Akka Actors in terms of performance and reliability and what configuration is possible to tune it for your workloads.”

Proposal 4:

Scala4Java

Approx time: 20 minutes

“This talk is some tips and tricks to write Scala-code that can be easily consumed by Java code, with dos and don’ts and examples from Scala projects.”

So what I need from you is to comment on this blog post what you’ find interesting of the above mentioned proposals, or if you have any other suggestions on what you’d like for me to present.

Thanks for helping me out!

Hardcore Pom

Wed, 08 Dec 2010 10:42:14 +0100

A fairly nice technique to speed up update- times in SBT is by using ModuleConfigurations. A ModuleConfiguration can be viewed as a filter on top of a repository, saying: “Only look in the repository if the artifact you’re looking for has the following group id.”

Pattern:

class MyProject(info: ProjectInfo) extends DefaultProject(info) {

object Repositories {

//Add repositories here, they won’t be used for artifact lookup since they’re inside the object

lazy val ScalaToolsRepo = MavenRepository(“Scala Tools Repository”, “http://nexus.scala-tools.org/content/repositories/hosted”)

//… add more repos here

}

//Here we add our ModuleConfigurations

lazy val scalaTestModuleConfig = ModuleConfiguration(“org.scalatest”, ScalaToolsRepo) //equiv of saying: “When you look for something with group id “org.scalatest”, look n this repo, but not otherwise

//Here we add our dependencies

val scalatest = “org.scalatest” % “scalatest” % “1.2” % “test”

}

That’s the entire pattern, this leads to extremely fast “sbt update“s and you are in more control of what gets downloaded from where.

However, I noticed that there is a big caveat.

Unfortunately SBT doesn’t take ModuleConfigurations into consideration when generating poms during publish-local and publish, this leads to poms that are missing a lot if not all of the repositories needed for its dependencies if you use the technique above.

With a big list of dependencies and ModuleConfigurations this is what I got in my pom:

<repositories>
        <repository>
            <id>ScalaToolsReleasesRepo</id>
            <name>Scala Tools Releases Repo</name>
            <url>http://scala-tools.org/repo-releases/</url>
        </repository>

</repositories>

Not what I had expected, there should be quite a few repos in there…

So I hacked together a small chunk of Scala that will post-process the poms and add all repos in your ModuleConfigurations, and I’ve named it McPom (ModuleConfiguration into Pom).

And this is the same artifact after McPom is thrown into the game:

    <repositories>
        <repository>
            <id>ScalaToolsReleasesRepo</id>
            <name>Scala Tools Releases Repo</name>
            <url>http://scala-tools.org/repo-releases/</url>
        </repository>
        <repository>
            <id>javanetRepo</id>
            <name>java.net Repo</name>
            <url>http://download.java.net/maven/2/</url>
        </repository>
        <repository>
            <id>JBossRepo</id>
            <name>JBoss Repo</name>
            <url>http://repository.jboss.org/nexus/content/groups/public/</url>
        </repository>
        <repository>
            <id>public</id>
            <name>public</name>
            <url>http://repo1.maven.org/maven2/</url>
        </repository>
        <repository>
            <id>CodehausRepo</id>
            <name>Codehaus Repo</name>
            <url>http://repository.codehaus.org/</url>
        </repository>
        <repository>
            <id>GuiceyFruitRepo</id>
            <name>GuiceyFruit Repo</name>
            <url>http://guiceyfruit.googlecode.com/svn/repo/releases/</url>
        </repository>
        <repository>
            <id>DatabinderRepo</id>
            <name>Databinder Repo</name>
            <url>http://databinder.net/repo/</url>
        </repository>
        <repository>
            <id>GlassfishRepo</id>
            <name>Glassfish Repo</name>
            <url>http://download.java.net/maven/glassfish/</url>
        </repository>
    </repositories>

Woot! McPom saves the day!

The only thing you need to do is to add the McPom trait to your project file, and mix it into the projects that needs it, and add the following override to them:

override def pomPostProcess(node: Node): Node = mcPom(moduleConfigurations)(super.pomPostProcess(node))

That’s it!
McPom can be found here
Enjoy!

SBT-fu: Publish privately

Tue, 30 Nov 2010 16:36:00 +0100

Have you’ve ever had the problem that you need to publish some Jars where your colleagues need to find them, but they are your secret web-scale sauce Jars and no one on the outside should be able to see them?

And you don’t get any permission to put the jars on a network share, and you’re not worthy of your own build server, says mr Infrastructure Manager?

And you happen to be using SBT?

There’s this wonderful service out there called Dropbox which is a small “cloud” storage solution that gives you a stash where you can put your personal files, and you have an option to have files available to the public, but they ALSO give you the possibility to _share_ folder with your trusted accomplices.

Here’s what you need to do:

1) Download and install dropbox

2) Create a new folder in your Dropbox root folder and name it something like “M2”

3) Add the following to your SBT project file

override def managedStyle = ManagedStyle.Maven

val publishTo = Resolver.file(“shared-repo”,

Path.userHome / “Dropbox” / “M2” asFile)

This tells SBTs “publish” action to place your artifacts in your “M2” folder in your dropbox root

4) Then add your awesome Dropbox M2 repo to the projects that needs to use the published artifacts

val SharedRepo = MavenRepository(“shared-repo”,
(Path.userHome / “Dropbox” / “M2”).asURL.toString)

5) Log onto www.dropbox.com and go into the “Sharing”-tab and share the M2 folder with all your awesome ninja buddies

6) Do an SBT publish, this places your freshly baked artifacts in your dropbox, and after Dropbox has synched it’s going to be propagated to your awesome friends.

7) No, seriously, you’re all done.

Enjoy!

Dispatchers in Akka 1.0-RC1

Mon, 29 Nov 2010 13:32:03 +0100

Curious about what we’ve done?

A lot of work has gone into the different dispatchers through Akkas relatively short but intense life so far.

Here are some news for Akka 1.0-RC1:

1) There is no public start/stop lifecycle anymore, the dispatcher will be started when it gets its first actor and will be stopped when the last actor leaves

2) The dispatchers will re-start when they get another actor if they were previously stopped

3) The dispatchers will only stop if a new actor hasn’t registered within X millis after the last one leaves. This timeout is tunable by default in your akka.conf: “akka.actor.dispatcher-shutdown-timeout”

4) All dispatchers now share the same unit test, this means that can ensure they have the same behavior i.e. respecting the Actor Model.

5) Since Dispatchers can be restarted you never need to worry about when and how to stop your dispatchers, and how to handle re-initialization.

We have also removed the Reactor based Dispatchers since they had lousy performance and were never used.

Some more good news is that we have managed to improve the performance even further, with ExecutorBasedEventDrivenDispatcher closing in on the HawtDispatchers excellent non-blocking performance.

Happy hAkking!

The Future is dead?

Mon, 29 Nov 2010 12:00:38 +0100

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!

Dependency Hell

Sun, 28 Nov 2010 22:07:39 +0100

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

Sun, 28 Nov 2010 10:01:00 +0100

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!

The self matters

Sat, 27 Nov 2010 15:02:00 +0100

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!

Akka 1.0-M1 is out!!

Thu, 21 Oct 2010 17:54:00 +0200

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!

Cheaper ThreadBasedDispatchers in Akka 1.0

Mon, 11 Oct 2010 13:27:39 +0200

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.

Dispatcher configuration for Akka 0.10

Thu, 19 Aug 2010 12:29:15 +0200

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!

Dining hakkers

Tue, 17 Aug 2010 22:06:00 +0200

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?

A new era

Sun, 18 Jul 2010 16:54:00 +0200

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!

Akka Message Routing: Part 2

Sat, 08 May 2010 22:20:00 +0200

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.

Akka Message Routing: Part 1

Mon, 03 May 2010 20:25:00 +0200

This is the start of a miniseries of the components available to do interesting message dispatching.

Here’s a common scenario: Depending on the message, I want to forward it to different other Actors.

Enough talk, here’s some code!

Can’t see the code?

That was simple enough, right? Stay tuned for the next part!