[zeromq-dev] Design Question

Nishant Mittal nmittal at rblt.com
Fri Jan 18 22:09:36 CET 2013


so to implement this the broker would keep a list of workers.. what if a
worker crashes and the router tries to send to it.. the guide mentions that
the msg would be silently dropped. can I set option SET_ROUTER_MANDATORY so
the send command returns an error and I try another connected worker?


On Fri, Jan 18, 2013 at 3:50 PM, Nishant Mittal <nmittal at rblt.com> wrote:

> thanks Harsh
>
>
> On Fri, Jan 18, 2013 at 2:42 PM, Harsh Doshi <hardos at gmail.com> wrote:
>
>>
>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>



-- 
*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/85ede89c/attachment.htm>


More information about the zeromq-dev mailing list