[zeromq-dev] disabling receiving messages from queue

Pavel Gushcha pavimus at gmail.com
Mon Aug 10 11:05:56 CEST 2009


2009/8/10 Pavol Malosek <malosek at fastmq.com>

Yes, i contribute this patch under MIT license, i'll glad to see it in repo.

 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!
>
> malo
>
>
>
> ----- Original Message -----
> *From:* Pavel Gushcha <pavimus at gmail.com>
> *To:* Martin Sustrik <sustrik at fastmq.com>
> *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.
>>>
>>> Thoughts?
>>> Martin
>>>
>>
>>
>  ------------------------------
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090810/aff58bbc/attachment.htm>


More information about the zeromq-dev mailing list