Skip to content
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

ZMQ_LINGER: NOP Implementation? #919

Closed
horus42 opened this issue Mar 12, 2014 · 13 comments
Closed

ZMQ_LINGER: NOP Implementation? #919

horus42 opened this issue Mar 12, 2014 · 13 comments

Comments

@horus42
Copy link

horus42 commented Mar 12, 2014

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.

@hintjens
Copy link
Member

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 notifications@github.com 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//issues/919
.

@horus42
Copy link
Author

horus42 commented Mar 12, 2014

The current stage of our development needs some code reorganization. I'll try to send/release the package later.

@sorenisanerd
Copy link
Contributor

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?

@thehesiod
Copy link

I'e run into an issue where it seems LINGER is not working on at least OSX: zeromq/pyzmq#832 I've verified this by adding a sleep before the socket close and my message gets delivered.

@hitstergtd
Copy link
Member

@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?

@thehesiod
Copy link

thehesiod commented Apr 20, 2016

per my testing it seems to be fixed by #1511 (used build 4.1.5)

@hitstergtd
Copy link
Member

Thanks! I will also await confirmation from @sorenh before closing the issue.

@sorenisanerd
Copy link
Contributor

Yup, totally fixed for me. Thanks!

@hitstergtd
Copy link
Member

Excellent! Thanks @sorenh, @thehesiod for confirmation. I will close this issue.

@sorenh,
Do you think we need to add some test cases for this?

@bluca
Copy link
Member

bluca commented Apr 20, 2016

@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 :-)

@hitstergtd
Copy link
Member

@bluca
Done! :)

@thehesiod
Copy link

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. :(

@thehesiod
Copy link

created new issue: #1922

bluca pushed a commit that referenced this issue Oct 31, 2023
Solution: add entry and mark it as related to Issue #1877 and PR #1511
bluca pushed a commit that referenced this issue Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants