[zeromq-dev] disabling receiving messages from queue

Pavol Malosek malosek at fastmq.com
Mon Aug 10 10:09:56 CEST 2009

Hello Gushcha,

If you could repost your patch under MIT license, we will merge it with the trunk.
One note that queue status can be kept in queues_t vector in api_thread - we will change that.

Thanks for your contribution!


  ----- Original Message ----- 
  From: Pavel Gushcha 
  To: Martin Sustrik 
  Cc: zeromq-dev at lists.zeromq.org 
  Sent: Friday, August 07, 2009 11:51 PM
  Subject: Re: [zeromq-dev] disabling receiving messages from queue

  Sorry, forgot about attach :-)

  2009/8/8 Pavel Gushcha <pavimus at gmail.com>

    Patch is attached. I didn't use "api->receive (&msg, false, 1 << queue_id1 | 1 << queue_id2)" because in this case api_thread_t is limited to 32 or 64 queues. I added std::vector<bool> to api_thread_t for storing queues statuses, and function set_queue_status(queue_,enabled_) for changing queue statuses.

    PS: may be adding function "bool get_queue_status(int queue_) {return queues_statuses[queue_-1];}" will be too good thing.

    2009/8/4 Martin Sustrik <sustrik at fastmq.com>

      Hi Pavel,

        Can I disable receiving messages from spcecified queue by api_thread_t::receive()?
        Real use case: my application has one api_thread_t, it receives requests, process it and sends responses. While processing request, it sends/receives messages to another applications. I want to implement limit for number of currently processing messages. Easiest implementation for me looks like this: when number of currently processing request goes above limit, i block receiving messages from requests queue. In this case only messages that used in processing will be received, no new request messages.

        Now i'm thinking about:
        1) more complex realization with two api_thread_t, non-blocking receive() and sleep() functions.
        2) more complex realization with blocking receive() but with two application threads with syncronization between them.

        May be threre is more elegant solution for my situation?

      No, there isn't :(

      What you speak about actually boils down to the need for polling on arbitrary subset of queues.

      Rather than implementing 1. or 2. you may consider submitting a patch to 0MQ that would allow for receiving only from a subset of queues. Say:

      api->receive (&msg, false, 1 << queue_id1 | 1 << queue_id2);

      Have a look at the implementation of zmq::api_thread_t::receive function. It's actually a pretty dumb loop that round robins through the list of queues and fetches a message from one of them.

      Making it ignore subset of queues seems to be a pretty trivial change.



  zeromq-dev mailing list
  zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090810/eeccae16/attachment.html>

More information about the zeromq-dev mailing list