[zeromq-dev] Multithreaded ZeroMQ servers

[Tom Quarendon]

I think what I want is essentially what is described in " A Load Balancing Message Broker". It's basically what I have written, though I did it slightly differently by having two 0mq queues, rather than having the "worker_queue" array. Basic point is the same, that the workers do a "request/reply" conversation with the main thread to get work, and the main thread has to service both the front end queue and the back end queue. 

-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
Sent: 04 January 2016 15:05
To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
Subject: Re: [zeromq-dev] Multithreaded ZeroMQ servers

If the work needed to handle a request is non-trivial, you have to pass it to other threads that can work on it.

If you want examples, in C, look at the zproto project, and as a worked example, study Malamute.

github.com/zeromq/zproto,
github.com/zeromq/malamute

-Pieter

On Mon, Jan 4, 2016 at 2:29 PM, Tom Quarendon <tom.quarendon at teamwpc.co.uk> wrote:
> Ah, sorry. C++
>
> -----Original Message-----
> From: zeromq-dev-bounces at lists.zeromq.org 
> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter 
> Hintjens
> Sent: 04 January 2016 12:02
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: Re: [zeromq-dev] Multithreaded ZeroMQ servers
>
> Tom, what language are you working in?
>
> On Mon, Jan 4, 2016 at 12:48 PM, Tom Quarendon <tom.quarendon at teamwpc.co.uk> wrote:
>> I’m confused about writing multithreaded servers with ZeroMQ.
>>
>> I have read the ZeroMQ guide and there’s a section “Multithreading 
>> with ZeroMQ” that has a description of how to write a multithreaded 
>> Hello World server.
>>
>>
>>
>> However there appears to be an assumption that the “work” of each 
>> request takes essentially the same amount of time. That is, the 
>> requests are dealt out to the workers with a dealer socket, and so 
>> the requests are just dealt out round robin aren’t they? So if one 
>> request takes a long time, you could get into the situation that it 
>> ends up with lots of requests queued up behind it for that worker, 
>> and all the other workers are idle. That doesn’t seem right to me. But I may be misunderstanding how it works.
>>
>>
>>
>> In my mind what you want to be able to do is somehow have all of the 
>> threads read from the same socket, or bind to the same external 
>> endpoint, so that the each time a worker does a recv it gets the next 
>> message that is in the input queue. Either that or you would appear 
>> to need each worker to disconnect from the inproc socket each time it 
>> has received a request to process so that it doesn’t get dealt any 
>> more, and then reconnect when it has finished, but that feels like it might be undesirably inefficient.
>> Either that or I have to have a big lock and memory fence around the 
>> input socket and just have each thread block waiting for the mutex 
>> and then reading the next message.
>>
>>
>>
>> What I seem to want to end up doing is writing my own simple thread 
>> safe in-process queue that I can just put the requests on to and have 
>> all of the worker threads read from. However I’d like to use ZeroMQ 
>> if I can, I just can’t work out how to.
>>
>>
>>
>> What am I missing?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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