[zeromq-dev] Design Question

[Harsh Doshi]

Btw I meant, it would block or drop messages if you use a HWM that is low
(but not 0). 0 should give you unlimited limit, but you will eventually
block or drop messages (tcp buffers filling up, etc).
Better load balancing will be achieved by using a router socket

On Fri, Jan 18, 2013 at 10:53 AM, Harsh Doshi <hardos at gmail.com> wrote:

> 0 would mean no limit. And it would either block or drop messages (I
> think).
> You'll need a router socket
>
>
> On Fri, Jan 18, 2013 at 9:25 AM, Nishant Mittal <nmittal at rblt.com> wrote:
>
>> i see.. that might explain why DLR is blocking.. so do you think if i set
>> the SND buffer to 0 on the dealer.. this will work? effectively giving me a
>> load balanced broker?
>>
>>
>> On Fri, Jan 18, 2013 at 11:10 AM, Stuart Brandt <stu at compuserve.com>wrote:
>>
>>>  Your DLR has a send_hwm too, so it's going fair queue against its
>>> outbound queues (which might not be full despite receiver not accepting
>>> more).  The mentioned load-balancing-message-broker or one of the reliable
>>> request-response patterns in section 4 will probably serve you better than
>>> trying to control routing by adjusting HWM.
>>>
>>>
>>> On 1/18/13 10:58 AM, Nishant Mittal wrote:
>>>
>>> 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 <%2B44%20%280%2920%207968%206828> - Fax: +44
>>>> (0)20 7930 8906 <%2B44%20%280%2920%207930%208906>
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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/20130118/7633be16/attachment.htm>