SQS , Apache Camel & Akka

Akka Apache-Camel Via SQS

This is an example project of how to setup a sample project using Akka, Apache-Camel and SQS together. Never heard of them or curious how they interact with each other?


Apache Camel is a rule-based routing and mediation engine.

What that basically means is that Apache Camel provides a common API for exchanging messages across a variety of platforms/protocols such as: HTTP, SQS, AMQP


Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM.

What that basically means is that Akka is a framework for writing code (known as actors) that lend to code to be easily distributed.


Amazon Simple Queue Service (SQS) is a fast, reliable, scalable & affordable message queuing service.

Why should you care!?

I’ve recently had the pleasure of releasing some code on heroku using the PlayFramework. Although deployment and initial setup was a breeze, I was bummed out to find that using Akka’s protocol was not doable as only standard ports on heroku are allowed (80,443). This leads to being unable to use Akka actors in a proper distributed model (i.e. they can’t talk to each other!)

Heroku has made a post where they outline using RabbitMq instead of the default Akka protocol however I did not find simple / ideal.

This brings us to this sample project! Leveraging Apache-Camel & SQS it was very straightforward to send messages to distributed actors.

Please check out the project on my Github page: https://github.com/fzakaria/Akka-Camel-SQS

Play! Framework with Akka actors on Heroku

Play! Framework

Recently for a project I’ve gotten to know the Play! framework and really the Scala language. The introduction into Scala was a very interesting curve, as I feel like I’m constantly flipping back and forth between having a solid understanding and a complete wtf confusion as I learn deeper pragmatic/idiomatic scala code. I have grown to love functional programming and can’t wait to flex some of the map / Option / fold / reduce in the new Java 8 language. Working with the Play! framework was a great first choice as there seems to be a good community and documentation however with any project the more complex it becomes the farther you go from being able to find good examples and into ‘icky’ situations’


I think you can’t get far into learning Scala with at least hearing about Akka and how cool it is. You read the introduction about Akka in plenty of Play!/Scala books and start to imagine how you’r architecture will look when everything is this beautiful encapsulated Actor. I’ve found however some nifty roadblocks setting it up and this blog post will pretty much be a brain dump on some of the issues I’ve resolved; namely cause of non-interoptiability with Heroku

So you want to use Akka with Play! ?

You want to use Akka with Play! ? Great! Play! actually bundles an Actor system already defined which is managed by the lifetime of the web server (whatever that really means) and come preconfigured to do some X thing which isn’t very clear. The first issue I ran into however is that I wanted to have Akka Actors to perform general book-keeping which meant they would have to be somewhat managed so that only a single instance is running every interval (i.e. Singleton). This sounds like it should be doable with Akka thanks to their SingletonClusterManager however you quickly learn that remote actors are not possible on Heroku. Bummer!

There is a blog post from Heroku on how to setup an Akka cluster using RabbitMQ as their event bus but it just seemed like way to much overhead for my simple use case. Here is some general steps to get Singleton Actors working in Heroku. The overall plan will be to nest a sub-project within your Play! application which contains it’s own Main class that will launch all singleton actors. This sub-application should then be launched only on a single dyno.

Setup a sub-module

Understanding the need for a sub-module is important or at least why I chose to do it this way. The way in which Heroku launches a Play! application is via a start script which is created from the SBT Native package installer when the stage command is executed. You can view the file for your application by opening up target/universal/stage/bin/ and you can see that is launches a NettyServer.scala class.

We could have easily included additional Main methods within our Play! project and included a worker in the Procfile which executes a java target (like what is happening within the run script) however I wanted to leverage the script which meant a new module/project has to be created (limitation of the SBT packager is that it only supports one main method per project). Much of the steps are followed idential from http://www.playframework.com/documentation/2.2.x/SBTSubProjects

Here are some interesting notes:

  • Don’t forget to set that the sub-project is an aggregate so that commands waterfall down to the inner project
  • If you want to re-use the configuration file from the higher project, make sure you reference the path now accordingly
  • Procfile entry: actors/target/universal/stage/bin/actors -Dconfig.file=../conf/application.conf -Dprocess.type=actors