test_socket_ops.test_send_receive_inproc_msg_vect test randomly failed about azmq HOT 5 CLOSED

I have another test that spuriously fails for the same reason, this flag
should be stripped before being passed to zmq.

On Fri, Nov 21, 2014 at 12:37 PM, Andrey Upadyshev <[email protected]

wrote:

test_socket_ops.test_send_receive_inproc_msg_vect randomly failed with
error Assertion !ec in void __cdecl
test_send_receive_inproc_msg_vect(void)[......\test\socket_ops\main.cpp:106]

Investigation gives that test fails with errno = 11 (EAGAIN). The reason
most probably because ZMQ_RCVMORE socket option is erroneously passed as a
flag for zmq_msg_recv. ZeroMQ treats it as ZMQ_NOBLOCK (aka ZMQ_DONTWAIT)
flag. When this flag is passed, if there is no message available, ZeroMQ
doesn't wait for a message but returns immediately with EAGAIN error (see
http://api.zeromq.org/2-1:zmq-recv). Note that this behavior is not
documented in later versions of ZeroMQ but still supported.

—
Reply to this email directly or view it on GitHub
#10.

from azmq.

What the reason to pass this flag to receive at all? It's a socket option not an operation flag.

from azmq.

The code that does the receive for the sequence of buffers in
socket_ops.hpp and receive_op.hpp attach meaning to it.

It is worth re-thinking, but the original intent was that receive on buffer
sequences would receive either discrete messages or parts of a multipart
message based on the presence of the flag...there is probably almost never
a use-case for the "not part of a multipart message" use case, so I am
leaning toward dropping the "receive n discrete messages before completing"
aspect of receives behavior.

On Fri, Nov 21, 2014 at 3:29 PM, Andrey Upadyshev [email protected]
wrote:

What the reason to pass this flag to receive at all? It's a socket option
not an operation flag.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from azmq.

Sorry for long delay - it was a weekend far from C++...
I propose to don't mix original ZeroMQ recv flags with AzioMQ added flags (specially if ZeroMQ constants with different meaning is used for it). Because they are just untyped bit flags they can be easily messed up and also using of ZMQ_RCVMORE (=1) hides the ability to specify ZeroMQ flag with the same value (It's not an issue for this particular case but this will not work as general solution). Either an additional parameter should be used for AzioMQ flags or special constants like AZMQ_xxx with unique values (like 0x80000000) should be used.

from azmq.

I concur. I will likely make this change sometime this week.

On Sunday, November 23, 2014, Andrey Upadyshev [email protected]
wrote:

Sorry for long delay - it was a weekend far from C++...
I propose to don't mix original ZeroMQ recv flags with AzioMQ added flags
(specially if ZeroMQ constants with different meaning is used for it).
Because they are just untyped bit flags they can be easily messed up and
also using of ZMQ_RCVMORE (=1) hides the ability to specify ZeroMQ flag
with the same value (It's not an issue for this particular case but this
will not work as general solution). Either an additional parameter should
be used for AzioMQ flags or special constants like AZMQ_xxx with unique
values (like 0x80000000) should be used.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from azmq.