Difference in message-passing model of Akka and Vert.x

[Bharath N]

Hi!

Am a Scala programmer and understand Akka from a developer point of view. I have not looked into Akka library's code. Have read about the two types of actors in the Akka model - thread-based and event-based - but not having run Akka at large scale I dont have experience of configuring Akka for production. And am completely new to Vert.x. So, from the choices perspective to build a reactive application stack I want to know -

1. Is the message-passing model of Akka and Vert.x very different? How?
2. Are the data-structures behind Akka's actors and Vert.x's verticles to buffer messages very different?

My project context is quite straightforward - its collection of data metrics from a firehose publishing large volumes at high speed. The business objective is to persist and show the data on UI in real-time with some simple data-aggregation and data-decoration in-between. The high-volumes and real-time aspects make me explore the reactive scala stack of libraries.

Thanks

Bharath 

[Ryan Chazen]

Hey

The general idea is similar.
In Akka you would create an Actor subclass that would receive messages which are serialized objects.
In vert.x you would create a verticle that would receive messages which are json objects.

The implementation specifics differ mostly in how vert.x is designed to be more language neutral through the use of json as opposed to language specific objects.
vert.x is also more of a complete platform while akka is a library. vert.x uses modules to allow for the use of easy interop between different languages, and vertx provides for easy network development with vertx specific apis.

As far as speed/high-vulume goes, vertx's use of simple json and using the impressive netty framework as a base give it a lot better performance in raw benchmarks - but obviously the bulk of your application performance will probably come from your own code so this isn't that big a concern, but it definitely helps. As far as real time aspects, neither platform is really designed for that but you might be able to use something like Azul systems JVM to help in that direction as it provides better real time guarantees than the Oracle JVM (I hear, anyway).

[Ryan Chazen]

Ignore my last line about real time - I assumed you were referring to the regular definition, eg: http://en.wikipedia.org/wiki/Real-time_computing
Obviously scala would be a bad bet for that as it's regular methods invoke large object creations etc, destroying any real time guarantees on GC.

You're referring to real-time + reactive to mean websockets and server side push of new information to the browser from the server, correct?
vert.x is particularly good at this because you can hook directly into the event bus from the browser - and as all messages are json, you can easily use them from javascript as they come in to update your website.
See: http://vertx.io/core_manual_java.html#sockjs-eventbus-bridge - this is in java though, but I believe the scala docs for the same functionality should be available soon(?)

[Galder Zamarreño]

On Tuesday, 4 February 2014 10:11:01 UTC+1, Ryan Chazen wrote:

Ignore my last line about real time - I assumed you were referring to the regular definition, eg: http://en.wikipedia.org/wiki/Real-time_computing
Obviously scala would be a bad bet for that as it's regular methods invoke large object creations etc, destroying any real time guarantees on GC.

^ That's not a problem solely of Scala. Any JVM language is always going to struggle with GC when it comes to running it in real-time guarantees. Also, there are always tricks you can use even in Scala to reduce memory consumption, such as using while loops instead of foreach...etc.