-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Occasional message loss executing a recv right after executing a send on a REQ socket #5
Comments
Have you been able to reproduce this problem with the latest versions of 0MQ and the Java binding? I would also advise to bring this up on the mailing list, in case you have not done it already. |
Since there have been no comments since September 2010, I will close this issue. Feel free to open a new one if necessary. |
Hello. I had a sudden detour from my project at the time, sorry for the (enormous) delay. This week I'll try to reproduce the bug with a more recent ZeroMQ version. |
Just to chime in, I couldn't reproduce the bug with the git versions of ZMQ stable and jzmq. Here's the test code: Java client: import org.zeromq.ZMQ;
public class ZQMRepTest {
public static void main(String[] args) {
ZMQ.Context ctx = ZMQ.context(1);
ZMQ.Socket socket = ctx.socket(ZMQ.REQ);
System.out.println("Connecting...");
socket.connect("tcp://127.0.0.1:5555");
System.out.println("Sending...");
socket.send(new byte[]{3}, 0);
System.out.println("Receiving...");
byte[] reply = socket.recv(0);
System.out.println("Received: " + new String(reply));
}
} C server:
|
OK, maybe this was something that was fixed since the initial report. More the reason to leave the issue closed. Thanks for telling us about your tests. |
Hi every one code :
the result is simply: Connecting... I'm beginner in zmq so may forget something . |
The scenario has two processes, one being a C server listening on a 0MQ REP socket "tcp://127.0.0.1:5555" and the other a Java client that issues requests to this server through a 0MQ REQ socket.
Right after receiving a request, the server replies with an ACK message. The server recv call is non-blocking. This way, the server and client flow would be:
C Server:
if(recv(socket, &request, ZMQ_NOBLOCK) == 0) {
// proccess reply
zmg_msg_close(&request);
send(socket, &reply, 0);
zmg_msg_close(&reply);
}
Java Client:
requestSocket.send(request_data, 0);
serverReply = requestSocket.recv(0);
The problem is that, even though the server send() call always returns 0, sometimes the client never receives the reply, staying blocked at the recv() call. Curiously, when I added a Thread.sleep(500); between the client's send and recv calls, I couldn't reproduce the problem after a couple dozen attempts.
One thing that also bugs me is that all blocking send() and recv() calls on the C server's REP socket set errno to EAGAIN, even when the call returns 0 and the message is correctly received. The zmq Manual (http://api.zeromq.org/) says that EAGAIN means "Non-blocking mode was requested and no messages are available at the moment", but I'm not even using non-blocking mode, so what gives?
The text was updated successfully, but these errors were encountered: