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

Problem: infinite hwm of version 4.2 lead to catch no msg #2228

Closed
laplaceyang opened this issue Nov 28, 2016 · 10 comments
Closed

Problem: infinite hwm of version 4.2 lead to catch no msg #2228

laplaceyang opened this issue Nov 28, 2016 · 10 comments

Comments

@laplaceyang
Copy link
Contributor

In release version of 4.2, we got a change in zmq::pipe_t::set_hwms, that 0 means infinite hwm.

 void zmq::pipe_t::set_hwms (int inhwm_, int outhwm_)
 {
     int in = inhwm_ + inhwmboost;
     int out = outhwm_ + outhwmboost;
 
     // if either send or recv side has hwm <= 0 it means infinite so we should set hwms infinite
     if (inhwm_ <= 0 || inhwmboost <= 0)
         in = 0;
 
     if (outhwm_ <= 0 || outhwmboost <= 0)
         out = 0;
 
     lwm = compute_lwm(in);
     hwm = out;
 }

but in some case ,I use the dealer mode, and set sndhwm after connect, lead to the hwm and lwm eq 0. which is not my origin idea.

Then if one side (dealer mode)(side A) is infinite hwm, and another (router mode)(side B) set hwm to a limit number. Then A side will never send_activate_write to the peer, accoding to the follow code.

    if (lwm > 0 && msgs_read % lwm == 0)
        send_activate_write (peer, msgs_read);

Finally, we got a full hwm by check_hwm, and reset_pollin. Since then, no message can be caught.

@laplaceyang laplaceyang changed the title infinite hwm of version 4.2 lead to catch no msg Problem: infinite hwm of version 4.2 lead to catch no msg Nov 30, 2016
@bluca
Copy link
Member

bluca commented Nov 30, 2016

This was changed to fix a bug, can't remember which, I'll dig it up later today

@bluca
Copy link
Member

bluca commented Dec 1, 2016

So I was thinking of this: #1649 but that's unrelated, I think.

Looking at the documentation, 0 meant infinite already in 2.1, so this hasn't really changed: http://api.zeromq.org/2-1:zmq-setsockopt

What changed is that now it's possible to modify the HWMs even after a bind/connect, since this PR: #1426 Is this what's causing you a problem?

Would you be able to upload to gist/pastebin a minimal test case that reproduces the issue you are facing? Thanks!

@laplaceyang
Copy link
Contributor Author

laplaceyang commented Dec 4, 2016

@bluca I just write a test case:
https://gist.github.com/laplaceyang/40374e2b40a5bfec56c7ce69749418eb

In my test case, I write some code to simulate a normal service, which is that frontend svr send msg to backend svr, and wish to recv response from backend.

and in the code, frontend svr set hwm after connect, and send total 5000 msg (should bigger than default hwm 1000)

and if I build this code with version 4.1.6, I can get what I expected
image

then, I build with 4.2.0, I can only recv 1000 msg from backend.
image

@bluca
Copy link
Member

bluca commented Jan 6, 2017

The gist is not longer visible

@laplaceyang
Copy link
Contributor Author

laplaceyang commented Jan 8, 2017

@bluca
https://gist.github.com/laplaceyang/40374e2b40a5bfec56c7ce69749418eb

here is the gist

I found something, that is
when we set hwm after connect, our hwm and lwm will be 0. because the outhwmboost and inhwmboost, which is prepared for inproc is default to be 0.

the pipe bind with socket_base and session_base is descibed as follow

socket_base  ( hwm 0, lwm 0 )
session_base  ( hwm 1000, lwm 500 )

session_base write the data to socket_base
but socket_base will never send_actived_write back to session_base
because of

    if (lwm > 0 && msgs_read % lwm == 0)
        send_activate_write (peer, msgs_read);

Thus, session_base is full.

So, I thank if we also set peer hwm when call set_hwm , will fix it.
Also the hwm/lwm should not always be 0 when use tcp and dealer and set hwm after connect.

I will try to fix it this week.

@laplaceyang
Copy link
Contributor Author

@bluca I just wrote a thread-safe solution by using command ,and include your pr.

laplaceyang@3062a97

By simply test, it works. But afraid of include some mistake.

@bluca
Copy link
Member

bluca commented Jan 10, 2017

Thank you for taking care of it! I can have a look in detail later tonight

@bluca
Copy link
Member

bluca commented Jan 11, 2017

@laplaceyang that looks fine to me. Would you please rebase it and send a PR?

@laplaceyang
Copy link
Contributor Author

laplaceyang commented Jan 11, 2017

@bluca pr has send, also with rebase my commit. #2302
Thankyou for your help

@bluca
Copy link
Member

bluca commented Jan 11, 2017

Thank you for fixing this! Closing as it's solved by PR #2302

@bluca bluca closed this as completed Jan 11, 2017
nickbroon added a commit to nickbroon/vermont that referenced this issue Sep 10, 2018
This allows calls set HWM socket options to happen on an unconnected
socket, thus working round ZMQ bug zeromq/libzmq#2228

This works with both versions of ZMQ that do and do not have the bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants