After grep'ing the code base it looks like that ZMQ_LINGER is a NOP for all sockets. E.g. when creating a REP zmq socket and then setting the sockopt ZMQ_LINGER to 0 (which comes in handy, when writing high-frequent unit tests) it doesn't really set it to value 0 (got already bound errors).
What is the intention of simply ignoring ZMQ_LINGER requests and just storing them in the options_t object?
Also would it be safe to add an actual LINGER implementation for e.g. REP, RES, PUB and similar?
Thanks for your Help.
Interesting. It looks like no-one ever tested this. Can you make a real
test case?
On Wed, Mar 12, 2014 at 3:14 PM, horus42 [email protected] wrote:
After grep'ing the code base it looks like that ZMQ_LINGER is a NOP for
all sockets. E.g. when creating a REP zmq socket and then setting the
sockopt ZMQ_LINGER to 0 (which comes in handy, when writing high-frequent
unit tests) it doesn't really set it to value 0 (got already bound errors).What is the intention of simply ignoring ZMQ_LINGER requests and just
storing them in the options_t object?
Also would it be safe to add an actual LINGER implementation for e.g. REP,
RES, PUB and similar?Thanks for your Help.
Reply to this email directly or view it on GitHubhttps://github.com/zeromq/libzmq/issues/919
.
The current stage of our development needs some code reorganization. I'll try to send/release the package later.
ZMQ_LINGER is handled at the session layer and in the internal communication pipes in zmq, not in each socket implementation:
https://github.com/zeromq/libzmq/blob/master/src/session_base.cpp#L446-L458
https://github.com/zeromq/libzmq/blob/master/src/pipe.cpp#L382-L447
I've just spent a few days digging into this (PR #1511) and it seems to work for me. What specifically is it that you feel doesn't work?
I'e run into an issue where it seems LINGER is not working on at least OSX: https://github.com/zeromq/pyzmq/issues/832 I've verified this by adding a sleep before the socket close and my message gets delivered.
@sorenh @thehesiod
Is this still an issue or can we close it?
@bluca
Do we want to use this as an issue to refer to #1511 or have you already opened one?
per my testing it seems to be fixed by https://github.com/zeromq/libzmq/pull/1511 (used build 4.1.5)
Thanks! I will also await confirmation from @sorenh before closing the issue.
Yup, totally fixed for me. Thanks!
Excellent! Thanks @sorenh, @thehesiod for confirmation. I will close this issue.
@sorenh,
Do you think we need to add some test cases for this?
@hitstergtd - I had already created #1877 when I backported to 4.0 and 4.1, but please do send a PR to both to mention this one too in the NEWS as it will be a useful reference :-)
@bluca
Done! :)
bad news, while the behavior is better, it appears it is not fixed based an more testing. The scenario I found it fails is if I have a bound PULL socket, and several dynamic PUSH sockets. I have verified that by setting SNDBUF to 16k and sending HWM + 1 messages of size SNDBUF and seeing that only then do all my messages pre SNDBUF flushing get sent. I'm guessing there is some extra buffering going on that's not being accounted for. I will post a working example here soon. :(
created new issue: https://github.com/zeromq/libzmq/issues/1922