[zeromq-dev] Just installed zmq and have a question about wiring and running a broker.

[Martin Sustrik]

Vineet Jain wrote:
>>> Good. My preference would be to create a global_queue in
>>> admin_client and let app1 and app2 bind to it (see p1.png).
> 
> However the admin client is just a client running on the admin's 
> laptop. It is not a long running process so that will not work.

Understood.

>>> If you except your logger to go offline or crash (do you?) you
>>> have to create a separate queue process (see p2.png). 'chatroom'
>>> application is actually a queue process. You can use it straight
>>> away, just discard the code that adds timestamps to the messages.
>>>  
> Yes. The loggers can go down for maintainance or can also crash (less
>  frequenetly I hope). So I do need a seperate process that would (as
> in p2.png) . The problem is that the chatroom app needs to know
> before hand the queues it's going to listne to.  In my case I'm
> hopping not to have to chage the queue process. Your example is
> simplified in that there is only one global queue. However, if I want
> to have a seperate global queue for each python logger, can the
> python logger process create a global queue in the queue process? or
> can the queue process only create and delete global queues in its own
> process?

The latter.

Actually the chatroom-like queue process IS a queue. Meaning that if you 
want N queues you simply run N processes.

> It's not a big deal, but it would be easier for a new person to get 
> started if zmq_server (or something similar) could be the host for 
> queues and exchanges out of the box. Then in my example, app1 and
> app2 would create two global queues on this central queue process and
> the admin client would just connect to it when needed. Is this not a 
> common use case?

That's the common use case for most of the environments. That's why 
almost all message queueing middleware supports the "broker" model - 
i.e. all the queues and exchanges hosted in a single process.

However, 0MQ focuses on a different market, specifically on the market 
for high-perf messaging. Here, the centralised broker design is 
inappropriate because broker itself becomes the bottleneck. It has 
limited CPU power, limited memory bus capacity, limited network 
bandwidth etc. What you want to do is to spread the load across your 
datacenter with no centralised bottlenecks.

Of course, zmq_server can be modified to host queues and exchanges, 
however, it's quite a lot of work and we are focusing mostly on the 
high-perf issues rather than on this kind of usability enhancements. 
Still, if there's anyone out there who would like to contribute this 
functionality, go on.

>>> Yes, that's the default. If there's no queue bound to an
>>> exchange, messages are discarded.
> 
> Ok thanks.

Martin