[zeromq-dev] OpenStack cloud API
sustrik at 250bpm.com
Tue Aug 3 09:22:18 CEST 2010
> 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
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.
Wow! Great! Finally the missing piece is not missing :)
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.
More information about the zeromq-dev