Akka 2.3.0 Major Release

March 5th, 2014 / Tales from a Trading Desk

Great to see the next version of Akka released that includes the following key features:

  • Akka Persistence
  • Java 8 support
  • Cluster improvements
  • Activator Templates

Cool take aways:

Akka Persistence also supports event sourcing

We have something brewing which will be more than just a replacement for Pipelines: inspired by RxJava we are working on implementing Reactive Streams for Akka which will allow declarative transformation of streaming data of all kinds, with proper handling of back-pressure and of course fully typed.

Akka Influence 2

March 5th, 2014 / Tales from a Trading Desk

Pigeon Framework now has a new name; Akka.NET.  Most excellent :)

Akka Influence

March 5th, 2014 / Tales from a Trading Desk

Thanks to a colleague for pointing me at the following:

  • Socko – An embedded Scala web server powered by Netty networking and Akka processing
  • akka.js – akka actors for JavaScript

MQTT with Vert.x

March 4th, 2014 / Tales from a Trading Desk

Couple of things worth possibly looking at:

Multiplexing and WebSockets

March 4th, 2014 / Tales from a Trading Desk

The C10k Problem, WhatsApp and more have over the years shown how web server application have improved to handle a high number of clients simultaneously.  High Scalability offer further food for thought:

In 2011 WhatsApp achieved 1 million established tcp sessions on a single machine with memory and cpu to spare. In 2012 that was pushed to over 2 million tcp connections. In 2013 WhatsApp tweeted out: On Dec 31st we had a new record day: 7B msgs inbound, 11B msgs outbound = 18 billion total messages processed in one day!

TypeScript 1.0 RC

March 4th, 2014 / Tales from a Trading Desk

Somasegar blogs that TypeScript is being used by Adobe, and a number of Microsoft products.

WhatsApp Architecture – Erlang

February 27th, 2014 / Tales from a Trading Desk

Interesting read over on High Scalability around WhatsApp. “hot-loading”- nice.  Some good lessons at the end of the article:

Measure. Remove Bottlenecks. Test. Repeat.

Erlang’s concurrency implementation is the Actor model – is the actor model a key part of the WhatsApp architecture success?

Erlang (/ˈɜrlæŋ/ ER-lang) is a general-purpose concurrent, garbage-collected programming language and runtime system. The sequential subset of Erlang is a functional language, with eager evaluation, single assignment, and dynamic typing. It was designed by Ericsson to support distributed, fault-tolerant, soft-real-time, non-stop applications. It supports hot swapping, so that code can be changed without stopping a system

Rexster and Scala

January 27th, 2014 / Tales from a Trading Desk

Graph databases have generate more interest in the last few years.  After blogging a bit about Neo4j, I’ve now started kicking the tires with Titan.  Specifically, given the Scala work I’ve been doing recently, I thought it appropriate to factor in some of the data into Titan, since it fit nicely.  Additionally, it makes a change from Neo4j.  Further, Titan has some interesting performance data available as food for thought.

Aggregating Messages using Akka – Part 2

January 23rd, 2014 / Tales from a Trading Desk

Following on from the last posting, and trying various variants of a solution to terminate the expect function rather than reply on the timeout for the happy path, I ended up with this hacked solution

var count=0


context.children.foreach( f => {count=count+1})

With count, I can now effectively terminate the collector as per the other bloggers solutions

def collectResults(force: Boolean = false) {
   if (results.size == count || force) {
      originalSender ! results.toList // Make sure it becomes immutable

Aggregating Messages using Akka – Trait and actorSelection

January 22nd, 2014 / Tales from a Trading Desk

Whilst on the plane back from NY recently I began to ponder about the aggregation pattern and akka.  Luckily, it would appear that Jamie Allen, followed by a few other bloggers have a solution that is well documented – the aggregator trait.

So, if I use the actorSelection to fire off messages to a group of identical actors e.g. algo’s or some such thing;

context.actorSelection("../<Parent>/*") ! <message>

I need to use the expect rather than the expectOnce to process the replies

JVM Performance Tuning

January 6th, 2014 / Tales from a Trading Desk

Random set of link that are worth reading/keeping for reference:

  • Everything I Ever Learned about JVM Performance Tuning @twitter
  • Synopsis of articles & videos on Performance tuning, JVM, GC in Java, Mechanical Sympathy, et al – Part 1, 2 and 3

Vertx ACL Event Bus Thoughts

January 5th, 2014 / Tales from a Trading Desk

Was thinking about authorisation/authentication and Vertx recently.  mod-auth-mgr looks interesting, but isn’t quite what I’m looking for – basically more of an ACL appropriate to addresses.  Curious if anyone has a solution?  Securing the bridge is worth a read, but again, not quite what I want.

On the topic of persistent messaging, Tim Fox’s Q&A from Devoxx 2012, touches on the direction Vertx will take.

Vert.x Thoughts – Cluster

January 3rd, 2014 / Tales from a Trading Desk

Lance’s “Async Data From Cluster to Browser” presentation provided in my view the golden nugget of information on slide 2, “application platform”.  If you haven’t played with Vertx yet, then I suggest you download and install.  As discussed before on this blog, reactive is “interesting”.    If you’ve played with Akka, and the Actor pattern, you maybe interested in Vertx when you read the Vertx manual on event bus, and HA/cluster features.  A distributed event bus, over a cluster of reactive Module/verticles.

Simple actor-like concurrency model. Vert.x allows you to write all your code as single threaded, freeing you from many of the pitfalls of multi-threaded programming. (No more synchronized, volatile or explicit locking).

System Under Specification

January 2nd, 2014 / Tales from a Trading Desk

Uncle Bob’s recent posting on Extreme Programming, a Reflection, should remind us all of the importance of testing:

Testing: The notion that programmers, and customers, write automated tests that verify that the production code actually does what they think it should. Nowadays we call this Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD).

Trisha’s ongoing series of articles centred around Spock is thus appropriate reading material on ways to test code, providing a handy reminder that basic unit testing really doesn’t cut it in today’s world of good software practices.  Spock leverages all the DSL :) power of the Groovy language to make testing a breeze.  As expected, Intellij support is provided.


January 2nd, 2014 / Tales from a Trading Desk

Oleg over on ZeroTurnaround offers an interesting read on log file generation based on an interesting logger in Python LogBook – Attack of the logs! Consider building a smarter log handler, and an example opportunistic-logger code base on github.  Curious if anyone has run something similar for a trading application in production – the financial committee is sometimes a little OTT on logging.

Definition of Done – Acceptance Tests

December 11th, 2013 / Tales from a Trading Desk

InfoQ has an interesting article on QA in Scrum.  The article offers a very simple Definition of Done (DoD) list, which is a good start – especially as in many organisations “Done” is often unfortunately accepted as a word, with no real evidence.  I’d offer that what is missing from this list one of the constructs of a good story – acceptance tests.  Additionally, I’d say that “acceptance test cases” need to be correlated back to acceptance tests on the story, else you could have somewhat of a delta between that the engineering team is using to test the story, and get to Done, and what QA is using to test the story – one source of truth.  Mike Cohn sums up acceptance testing quite clearly for all involved in “testing” stories that need to be deemed “Done”:

Reactive Programming for Databases

December 9th, 2013 / Tales from a Trading Desk

Slashdot has an interesting article by Val Huber.  Espresso Logic web site provides more detail on Reactive Service for SQL Data, which primarily creates REST API’s over databases, with the REST API injected into the path to the database, and thus offering the reactive layer.  No surprise to find JavaScript as the language of choice for the business logic (reactive layer).  Architecture overview available here.

Expose your enterprise data as RESTful APIs to customers and partners with complete row and field-level security – no programming

Liquidity Management – Execution Venue Pricing

December 3rd, 2013 / Tales from a Trading Desk

During some late night code sessions, I’ve refactored the previous blogged actor liquidity management code, and borrowed a few lines of code from Typesafe’s Reactive Stock sample – specifically the price generator:

  // A random data set which uses stockQuote.newPrice to get each data point
  var stockHistory: Queue[java.lang.Double] = {
    lazy val initialPrices: Stream[java.lang.Double] = (new Random().nextDouble * 800) #:: => stockQuote.newPrice(previous))

  // Fetch the latest stock value every 75ms
  val stockTick = context.system.scheduler.schedule(Duration.Zero, 75.millis, self, FetchLatest)

I also made a basic start to adding Testkit test coverage:

Liquidity Management Through Actors and Futures

November 28th, 2013 / Tales from a Trading Desk

Based on the coolness of Typesafe’s recent blog postings on akka, and a little time late one day recently – actually I think it was post midnight, but who’s counting.  I decided to take the standard liquidity management high level architecture, and implement the simple/basic flow using akka with futures.  Similar to the view provided by the recent Typesafe survey, I failed to leverage TestKit :(

2013 JVM Language Summit

November 26th, 2013 / Tales from a Trading Desk

Few stand out items from the JVM Language Summit 2013: