[zeromq-dev] OpenStack cloud API

[Martin Sustrik]

Pieter,

> That's the nice thing about standards, there are so many to chose
> from.  I see RabbitMQ finally has experimental support for AMQP/0.9.1,
> the nicest of the family but still a dead branch.  Nova is a perfect
> case for 0MQ, an elastic distributed application.  Putting a broker in
> between every component adds a few hundred microseconds to every
> single hop.  So as soon as performance starts to become an issue, the
> broker and complex protocol will have to go.
> 
> The authors write "...nodes and controllers communicate exclusively
> across the message bus (AMQP, currently)" so presumably they are open
> to alternatives.

I'm going to write a simple 0MQ/AMQP adapter shortly so 0MQ applications 
will be able to join the OpenStack message bus easily (there's RabbitMQ 
running at it's core).

However, speaking about communication with existing messaging 
infrastructure, there's a project that would be extremely interesting 
from both adoption and commercial perspective, namely creating a JMS/0MQ 
bridge.

While an free JMS solution, such as HornetQ can be used for the 
development, the primary goal would be to port it to WebSpehereMQ JMS 
provider (also Tibco, Oracle's AQ, SonicMQ etc.) thus unlocking some 90% 
of the corporate messaging market.

If anyone is interested in that kind of thing, I can supply overall 
design of the thing.

> Speaking about getting zmq adopted wider, I've started, finally, on
> the User Guide.  Here's what there is so far... comments welcome.
> 
> http://www.zeromq.org/docs:user-guide

Wow! Great! Finally the missing piece is not missing :)

Some comments:

1. Zed's introduction incorporated into the document seems a bit 
superfluous. Moreover it focuses on message/stream dichotomy which kind 
of suggests that 0MQ is a dumb message delimiting wrapper.

2. The examples should be in C given that accompanying text uses C API.

3. Using multi-threaded server as a first example is overly complex IMO. 
Single-threaded server would do. Also, it may be worth of writing in 
Python so that simplicity of 0MQ is even more clearly pronounced.

4. There's a factual error in the part concerning messages. When you 
send a message, your zmq_msg_t object remains empty. Thus you have no 
access to the underlying data to spoil. The two ways to mess it up is 
either creating a copy of the message (zmq_msg_copy) before sending it 
or by using the buffer handed to zmq_msg_init_data even after the 
message was sent.

Martin