Distribution

Clustering data and messaging services is well known as a source of unnecessary expense. This is not the case with Erlang because clustering is built-in.

Erlang's process model is inherently distributed and its concurrency model makes writing highly concurrent applications much simpler than, for example, Java. This allows much more successful utilisation of parallel hardware. For example, utilisation of multi-core CPUs is simple, whilst several of the core concepts of Erlang significantly reduce the probability of deadlock and live-lock. This means that little effort needs to be invested in RabbitMQ for it to take advantage of upcoming parallel hardware architectures, whereas a more typical threading model, such as that employed by Java, would require much greater effort. In commercial terms, this has a significant benefit of allowing immediate return from investments in multi-core and 64-bit architectures.

Although a process in Erlang is bound to one node, if the communicating parties are distributed, the syntax of communication between processes does not change. As a result, RabbitMQ scales very well with additional hardware as it is trivial to create exchanges and queues on non-local nodes, with the Erlang runtime system taking care of message routing transparently. The payoff is that there is no further development work needed for deployment on large clusters or grids, even remotely over a WAN. As a result, RabbitMQ can be treated as a service rather than just a server.

Live code upgrade

Large users of messaging technology, e.g. investment banks, often have hundreds of separately managed messaging nodes or routers. However, as with distribution, Erlang does not suffer from the maintenance and administrative problems associated with multi-node or complex deployments.

Erlang supports the ability to upgrade the code running on a node without taking the node down. This can be engineered so as to work across groups of nodes. Programmatic hooks allow modules to be informed when there is a new version of the module available and to migrate state safely to the new module version. This would, for example, allow RabbitMQ to be deployed supporting version "a" of AMQ and then when version "b" becomes available and is then implemented, for it to be rolled out into the live system, giving the live system the ability to support both versions of the specification with no downtime. This is obviously a very attractive feature for high availability purposes and for ease of system administration of upgrades.

Built in Process Monitoring and Control

Erlang is designed so that an administrator can enter the system from any one of multiple specified points, from which the whole system can be managed.

When a process spawns a child process, it creates a link to the child process. This means that the child process is informed as soon as the parent process dies and vice versa. Thus it is simple to respond to failures and process-deaths, and to create replacement processes that take over the role of the failed processes quickly and automatically. It is obviously again a very desirable feature for high availability of the system, for example hierarchical node management, peer to peer clustering, etc.

Predictable High Speed

Erlang, and functional programming languages in general, by design do not suffer from garbage collection pauses as much as languages such as Java can do. Additionally, Erlang's communication operations are well known for their high through-put and low latency.

Interprocess communication in Erlang is extremely fast. Consequently, the latency of RabbitMQ is low without our having performed any significant optimisation work in order to achieve this.

Erlang does have a garbage collector and it works by mark-sweep across each process space, stopping the process whilst it cleans the heap. However, this has a much lower impact on Erlang's performance than say, on Java's performance, as Erlang processes typically make much less use of the heap. Additionally, Erlang uses a partitioned heap, creating a separate heap for each process. This is based on the Erlang maxim of having no shared data between processes. As a result, each process heap stays much smaller, and garbage collection is much faster. Consequently, performance is much more predictable.

Point to Point

Tibco Rendezvous is a commonly used messaging product because its multicast based implementation leads to high through-put publish-subscribe solutions, e.g. for sending prices to traders. However, multicast based solutions suffer from problems such as network storms which can lead to catastrophic performance. Recently, messaging implementations have emerged which achieve similar performance to multicast but which avoid the problems by, in fact, being point to point. The intention of the AMQ protocol appears to be to encourage this, and Erlang is particularly well suited to this case.

Erlang uses TCP/IP for communication between Erlang nodes although alternative carriers can be used. As a result, communication is only point-to-point between communicating Erlang nodes, avoiding multicast network storms. Furthermore, the guarantees of message delivery between Erlang nodes are achieved through the guarantees of TCP/IP, making for a reliable communication network.

Enterprise Ready

As a result of Erlang's target domain of the telephony industry, it benefits from almost 15 years of development and deployment in enterprise grade applications. This includes, but is not exclusive to, its extreme reliability, process monitoring and inspection tools and the incremental improvement of the Erlang code base over an extended period of time.

Additionally, there are many tools available for the monitoring and observation of nodes and groups of nodes. A list of such tools that are shipped with Erlang is available here.

Because they have been Open Source since 1998, the Erlang language and runtime have also benefitted from multiple end-user experiences and contributions.

Portability

Erlang is available for download for Windows in precompiled form along with source being available for Windows and other platforms.

Ericsson have a "Daily Build and Test" that runs on:

• Solaris/Sparc 2.8
• Linux/Suse x86 9.2
• Linux/Suse Amd64 9.2
• Linux/Suse Amd64 10.0
• Linux/Montavista PPC 3.1
• FreeBSD x86 5.0
• Mac OS X 10.3.9
• Mac OS X 10.4.6
• Windows XP
• Windows 2003