[zeromq-dev] Controlling thread affinity in a DEALER socket

[Peter Friend]

One of the themes running through the guide is that you should avoid mutable state that needs to be shared among threads, and send messages instead. So to handle the "sockets are not thread safe" you need a socket created in each thread that connects to some common endpoint. I recently had to deal with this in Java.

// create inproc listener socket for messages from threads
_inproc_sock = ctx.socket(ZMQ.DEALER);
_inproc_sock.setIdentity("inproc".getBytes());
_inproc_sock.bind("inproc://service");

>From there I create an Executor thread pool for handling tasks. I create a class which implements ThreadFactory which creates threads that open a socket in start():

_socket = ctx.socket(ZMQ.ROUTER);
_socket.connect("inproc://service");

The thread then writes the responses to this socket, using an address frame of "inproc".

The inproc socket is added to the poll fd list and is checked in the main polling loop. If there is a message on the inproc socket (which will be a response message from a thread) I just send it back out the socket that the request came from. There is more detail in the guide:

http://zguide.zeromq.org/page%3aall#toc43

How you dole out requests to threads depends on your needs. In my case I pass the message frames to the thread pool in a task object and handle the addressing issues in the code, so the inproc socket is only used for sending the response back. I suppose you could use the inproc socket to send the message to the worker thread, but I don't see how that could work with a thread pool since the thread that gets sent a message could already be processing another task. 

Peter


-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Brad Taylor
Sent: Thursday, December 20, 2012 3:22 PM
To: ZeroMQ development list
Subject: [zeromq-dev] Controlling thread affinity in a DEALER socket

In reviewing the guide, the multi-threaded patterns uses a proxy that has a DEALER socket for dealing the message to a worker.  We have a requirement to handle particular messages to particular threads.  That is the message can only be handled by a given thread.  Is there a simple pattern or technique, that would let us decide which backend socket to "deal" the message to?

In the bigger picture we want a multi threaded server, that listens on a single port.  There will be n-number of worker threads, where each worker thread can service requests for a given resource.  The resource is identifiable as part of the message.  We want to use the overall request-reply pattern.  That is the client issues a request, the server receives the message and passes the request to a specific worker thread, based upon message content.  The worker thread does the work and sends a reply to the client.  Thus we get parallelism in carrying out the work.  We have looke at some of the patterns.  However the "sockets are not thread-safe" statement worries us.

Any thoughts or guidance would be appreciated.

Thank  you

Brad Taylor 

_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev