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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
