Question

I’m interested to comparison between various approaches to scalability & concurrency including CCR & DSS framework model. I would be especially interested with comparison with Hadoop and Erlang style concurency

Answer 1

I have looked at CCR, DSS and Erlang, although of these, I have shipped only CCR into significant production code. I’ve never looked at Hadoop.

Erlang’s concurrency derives from its implementation of the Actor model. Each ‘process’ has a mailbox and retrieves messages from it, one at a time. A process with no messages to handle blocks no thread. Conversely, processes with work to do are scheduled across available cpu with none of the underlying machinery exposed. Additionally, processes communicate via message-passing with either cloning/immutability ensuring that P1 and P2 never logically share the messages that pass between them.

My feeling is that it is the non-blocking nature of message sending and receiving that gives Erlang its reputation for scalability on a single (possibly multi-core) machine. Essentially, processes with work to do are scheduled efficiently across the available resources and quiescent processes consume nothing but memory. By processing one message at a time, each guaranteeing message stability, the developer no longer has to worry about things like ‘race-conditions’.

CCR is a set of low-level asynchronous message passing primitives. One of the simpler ones is Receive that does a receive a la Erlang. But there are more sophisticated primitives, such as Join (receive a message all of some channels) and Choice (receive a message from any of some channels), which can be nested and composed in interesting ways. These primitives are also non-blocking. Receivers generate tasks (to handle the messages) into 1..n task queues, which are serviced by a small number of threads.

My guess is that, ignoring (important!) platform differences, the basic task-scheduling routines of each are in basically in the same ball-park. However, Erlang is a language and a platform with a fixed (Actor) model baked in. The CCR is neither of these things, its just a library and you can use/abuse it more freely.

DSS is a programming model, that builds on CCR. It has services (Erlang = processes), it mandates asynchronous message passing (with full cloning by default) as the only form of inter-service communication, and the only handle the outside world has to a service is its URI (Erlang = PID). Like Erlang, there is essentially no difference between invoking a local service and remote one, although (de)serialisation occurs in the latter case.

DSS also has a RESTful model, meaning that services typically expose a fixed and common set of operations, and that the state of the service should be considered a resource manipulated by these operations. Contrast this with Erlang, where arbitrary messages can be sent to a process. DSS services can use the full set of CCR primitives in talking to other services, which can be very useful for things like distributed scatter-gather operations.

Ultimately, DSS is just a framework with supporting libraries, not a language or VM, so there is considerably more ‘ceremony’ involved in writing even a single DSS service as opposed to writing an Erlang process.

In terms of concurrency, all provide the primitives required to write code that is safe and efficient under multiple threads of execution, without worrying about those threads of execution. I think that’s where most developers want to be heading.

In terms of scalability, that’s a tougher one to answer as that’s as much about system design as it is the tools used. Do you mean scalability on a single node, i.e. as you add cores, or as you add nodes? CCR has nothing to say about the latter. Both DSS and Erlang support fairly efficient binary formats for wire transmission. DSS inherits its resource-oriented view of the world directly from http, which should tell you something about its potential scalability, but it does this at some restrictions in the programming model.

A couple of technical points. A single DSS service consumes more memory (~2K) than a single erlang process (300-400 bytes). Also, each DSS service gets its own task queue and there’s an upper limit (~10000) on the number of task-queues that can be efficiently processed by the CCR. I don’t have numbers on any such upper limits for Erlang but suspect it might be higher than this.

Having said all this, if you’re on the .NET platform you’d be doing yourself a favour by taking a serious look at the CCR. I’ve found it to be very powerful, especially for reactive event-driven programs.