CastleZMQ tests "Loop forever"

[tcl...@ffa-geosciences.com]

Hi, we're looking to upgrade ZMQ to 4.0.5, and are looking for a quality binding. CastleZMQ's binding looks the best, but we have concerns that some of the tests are failing and that some get stuck in an infinite loop.

Steps:

• Pulled down the source from "master" (https://github.com/castleproject/castlezmq/archive/master.zip)
• Built and ran the n-unit tests
• Investigated failing tests and found certain tests that loop forever

Problems:

• All the RemoteRequestServiceTestCase.cs tests fail, due to StubSocket not being castable to Socket
• Tests "when_recvTimeout_recv_should_return_null", "creating_pub" and "creating_sub_and_subscribing_to_specific_weird_topic" all loop forever

-------------------------------------------------------------------------------------------------------------------------------------------------------------

The culprit appears to be in https://github.com/castleproject/castlezmq/blob/master/src/Castle.Zmq/Socket.cs (The issue is in red):

                public byte[] Recv(bool noWait = false)  // noWait is set to false

{

EnsureNotDisposed();

using (var frame = new MsgFrame())

{

var flags = noWait ? Native.Socket.DONTWAIT : 0;

again:   // We loop here forever

var res = Native.MsgFrame.zmq_msg_recv(frame._msgPtr, this.SocketPtr, flags);

if (res == Native.ErrorCode)    // res always equals Native.ErrorCode (-1) for the "looping" tests

{

var error = Native.LastError();

if (error == ZmqErrorCode.EAGAIN || error == ZmqErrorCode.EINTR) goto again;  // It's always EAGAIN (11)

if (LogAdapter.LogEnabled)

{

LogAdapter.LogError("Socket", "Recv interrupted with " + error + " - " + Native.LastErrorString(error));

}

Native.ThrowZmqError(error, "Recv");

}

else

{

return frame.ToBytes();

}

}

return null;

}

Apart from the fact that these tests are failing, we're concerned that if you've set ZMQ noWait to be false, shouldn't *zmq_msg_recv* be blocking, rather than returning an instruction that you should block? Or is this something we don't understand about ZMQ's behaviour?

This definitely looks like the best binding available for us, and I'm guessing you've solved these issues internally?

Thanks for any help!

[hammett]

Hi,

I guess we use the polling more than recv directly. I'm happy to fix it with a pull request if you have one.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,
hammett
http://www.d-collab.com/
http://www.hammettblog.com/