-
Notifications
You must be signed in to change notification settings - Fork 58
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
Seemingly unconfigurable receive timeout #87
Comments
So, fair warning, it's been a long time since I've really dealt with this code. You may be running into the zookeeper gem's DEFAULT_RECEIVE_TIMEOUT_MSEC which is 10s. This was based on the default cluster timeout of 20s (at the time of writing). You should try creating your ZK instance like: zk = ZK.new(:receive_timeout_msec => 30_000) # 30s and see if that helps |
Thanks for your suggestion! I'll absolutely give that a shot when I get into work and I'll report back on it. |
Just fyi, I tried the |
My recollection was that this trick worked at the time. That said, this library hasn't been given a significant update in years, and doesn't even really support ruby 2.0. The potential for bitrot is tremendous, and you should probably find another library. |
Hello!
I've been experiencing a problem with timeouts in the zk gem. When I make a
.children
call on a very large zk system, I time out after exactly ten seconds.I'm aware (now, anyway) that the connection timeout established in
ZK::Client::Threaded
is not the same timeout I'm looking for. I also noted this bit on line 63 ofthreaded.rb
:However, I'd like to assume that the session timeout is not what I'm looking for either.
Is the timeout I need to prevent the following trace exposed anywhere?
Thank you!
The text was updated successfully, but these errors were encountered: