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

[Matt Weinstein]

There's an ongoing discussion about this.  A hard failure may be  
difficult for some environments, you're correct.

A thought --

I'm beginning to think that error options should be a ØMQ compile time  
option, e.g. replace all of the asserts with e.g.:

	if (rc)
		return zmq_error(int errno, const char* what);

Then zmq_error(...) can abort or return an errno depending on the  
compile time (or dynamic?) implementation of zmq_error.

If there are places where something can't happen, you can call  
zmq_abort(...) with the same args.




On Aug 12, 2010, at 3:21 PM, Alexey Ermakov wrote:

> 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
>
> _______________________________________________
> 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/d89edf3f/attachment.htm>