req/rep not working properly about em-zeromq HOT 12 CLOSED

Hi,
I am a little confused with your client code, your are waiting until the socket becomes writeable to print a message saying you received a message ? Did you meant on_readable ?

If the text printed are wrong and what you were expecting is that the socket becomes writeable only if there is a server on the other side I do not think it will work that way since zeromq manages the send queue itself, on our side the socket will be immediately writeable and will become no longer writeable only when the zeromq queue is full.

Maybe your code would work as expected if you set the send queue size to 0 but it would completely defeat the purpose of using zeromq.

from em-zeromq.

Agreed w/ schmurfy, you want to hook into on_readable for a req socket, since a req_socket is only readable after a reply has come through.

from em-zeromq.

If I use on_readable I never get anything back. I can see the reply on the network (using wireshark) but notify_readable is simply never called and consequently neither is on_readable.

from em-zeromq.

There is indeed something broken with REQ/REP while XREQ/XREP work fine, I can see the packet coming at the network level like you but it never triggers the callback. I started looking into it but found nothing yet, I was using zeromq 2.1.6.
@filterfish : which zeromq version did you tried with ? I t may help fix this.

from em-zeromq.

I'll take a look at this later today, but I should mention, xreq/xrep are a much better match for eventmachine. Is there a reason you need blocking behavior?

from em-zeromq.

@schmurfy I used version 2.1.4 (Debian experimental).

@andrewvc What I'm actually after is to have a way on knowing if there is a listener when sending messages. PUSH would be ideal but with em-zeromq messages are discarded if there is no listener. If I remove the ZMQ::NOBLOCK in Connection#send_msg then the sender blocks but obviously this blocks the whole reactor. Is there a way of having the call to Connection#send_msg block but not block the reactor much in the same way as Context#connect blocks but doesn't block the reactor?

from em-zeromq.

Sending messages with zeromq is never blocking (in the nomal case at least), that is one of the feature of this library, as you pointed it is true that the power zeromq gives us does come with a price: you never known if there is someone on the "other side" of the connection when you send a message.
What happens when you send a message depends on the type of socket you used, you can check here for a complete reference of the sockets types and their behaviors: http://api.zeromq.org/2-1:zmq-socket .
For REQ/XREQ the messages are queued until a listener appears if I remember well.

You can check http://zguide.zeromq.org/page:all, there are great examples of real architecture applied to zeromq, it may helps you find a way to fit your needs with zeromq.

from em-zeromq.

I redid some tests and I am starting to wonder if the problem is not that the fake FD zeromq returns to us just not work as expected with REP/REQ in the 2.1.6 release.
I tried simple blocking read/write tests with ffi-rzmq and they worked as expected.

from em-zeromq.

Hmmm, that's possible. My understanding of how those FDs work is that 0MQ uses them internally to signal communications (like message arrived). Any chance you could gist the tests schmurfy?

from em-zeromq.

BTW, the fake FDs are actually unix sockets.

from em-zeromq.

I have no test that shows a failure, what I did is check that REP/REQ where actually working as intended both in C and with ffi-rzmq, here are both tests if they can be of any use: https://gist.github.com/961468 .

from em-zeromq.

Pending new information, this doesn't seem to be an actual issue.

from em-zeromq.