[zeromq-dev] Design Question
Nishant Mittal
nmittal at rblt.com
Fri Jan 18 16:58:50 CET 2013
aah, i remember that now.. i'll look into it again.
my hope was DLR would "try" to fair queue but if the worker was not
accepting any more msgs.. DLR would try the other worker.. but its not
doing that.
thanks
On Fri, Jan 18, 2013 at 10:49 AM, Andy Ballingall TF <
ballingall at thefoundry.co.uk> wrote:
>
> On 18 January 2013 15:14, Nishant Mittal <nmittal at rblt.com> wrote:
>
>> I have 3 workers (REP) connected to a DLR socket. each worker takes a
>> msg, processes and responds... however, as the DLR socket fair-queues..
>> requests are sent like this...
>> 1st -> 1st worker
>> 2nd -> 2nd worker
>> 3rd -> 3rd worker
>> 4th -> 1st worker
>>
>> problem is if the 1st worker is still busy with the 1st request the 4th
>> request waits... even if the 2nd and 3rd workers are free. I am "guessing"
>> its because of the receive buffer on the REP socket..
>>
>> is it possible to fix this by setting the ZMQ_RCVHWM to 0?
>>
>>
> I'm not sure if it will help your use case, but have you read through the
> load balancing example in the guide?
>
> http://zguide.zeromq.org/page:all#A-Load-Balancing-Message-Broker
>
> Workers are only given work to do if they are free, so you never get the
> problem of some workers having a queue of things to process while others
> are idle.
>
> Andy
>
>
>
>
>
> --
> Andy Ballingall
> Senior Software Engineer
>
> The Foundry
> 6th Floor, The Communications Building,
> 48, Leicester Square,
> London, WC2H 7LT, UK
> Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906
> Web: http://www.thefoundry.co.uk/
>
> The Foundry Visionmongers Ltd.
> Registered in England and Wales No: 4642027
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
--
*Nishant Mittal*
Director, Product Development
*Rosenblatt Securities Inc*.
20 Broad Street
New York, NY 10005
Direct: 212-607-3159
Mobile: 646-504-2629
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130118/2c2eca0e/attachment.htm>
More information about the zeromq-dev
mailing list