[zeromq-dev] [jzmq] xreq/xrep sockets and thread safety

[Alexey Ermakov]

Thanks, that sounds like an easy solution.
I'm using jzmq, though, so I'll have to implement the device myself (there
are no java bindings for zmq devices; my c++ is rusty, so I doubt I'd be
able to implement them with our current time constraints; I don't like the
idea of having to configure and spawn an additional process for this).
I've tried playing with XREQ/XREP sockets and they seem simple enough.
There's a catch, though: if I do a send() a message to an XREP socket with
no ZMQ_SNDMORE set (and I haven't sent the identity first), it crashes with
an assertion failure, instead of returning an error. Is that really a good
idea, considering that it's a rather simple mistake to make and the library
is supposed to be used in other languages? Current behavior it means that if
I have any sort of bugs in my device code, the whole JVM will crash.

On Thu, Aug 12, 2010 at 9:23 PM, Matt Weinstein <matt_weinstein at yahoo.com>wrote:

> The DEVICE service thread is not designed for processing "stuff".
>
> One design: two threads on your side -- one which is an async request
> thread (unless you get some form of signal) and an async response
> handler.
>
> [ clients ] [ REQ ] == [ XREP ]  == [ DEVICE ] + 2 streams:
>
>   ==> [ ZMQ_PUSH ] == [ ZMQ_PULL ] [ ASYNC_REQUESTER ]
>   <== [ ZMQ_PULL ] == [ ZMQ_PUSH ] [ ASYNC_HANDLER ]
>
> I'm presuming the async API can efficiently share state between the
> two ASYNC_* threads.
>
> What are you actually making requests to...?
>
> Use zmq_reactor to build DEVICE (use the poll_items branch).
>
>
> On Aug 12, 2010, at 1:09 PM, Alexey Ermakov wrote:
>
> > Hi everyone,
> >
> > I'm trying to figure out how to deal with the thread safety
> > restriction of 0MQ sockets. As I understand, they are bound to a
> > thread, which means that I write/read to the same socket from
> > multiple threads (which is possible with Java Posix socket
> > wrappers). I'm trying to figure out how to implement a rather simple
> > task and I can't think of a decent solution.
> > My application is a Scala-based server that has an XREP socket,
> > processes the requests, and replies back. The catch is that request
> > processing is implemented by forwarding a request to another service
> > using an asynchronous API. How am I supposed to send the replies
> > back, if the XREP socket is bound to the thread that is basically
> > blocked on "while (true) socket.recv()"? I suppose I could do a 50ms
> > poll on the socket and then process the replies (fetching them from
> > a LinkedBlockedQueue or something), but that would be inefficient,
> > because requests/replies happen much less frequently. Another
> > solution would be replacing all inter-thread communication with 0MQ
> > sockets and doing a poll() on these sockets in the request handler,
> > but that doesn't sound very nice.
> > Is there an easier solution I'm overlooking?
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100812/68f0b028/attachment.htm>