Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Implementation of the Zookeeper::Continuation OPERATION_TIMEOUT is limited in usage #27

NeMO84 opened this Issue Nov 1, 2012 · 3 comments


None yet
2 participants

NeMO84 commented Nov 1, 2012

The implementation makes an assumption of the session timeout value on the server side which is configurable. This setting should also be configurable and retain the default operation timeout. If a developer decides to use a different timeout value they should have the flexibility to configure that change.


slyphon commented Nov 1, 2012

This is not totally accurate. The client negotiates a session timeout with the server, and this is currently hard-coded to 20s. The reasons for this are mainly legacy (it's the way the library was implemented when I took it over) and I never had a real reason to change it.

The OPERATION_TIMEOUT value is intended to be a failsafe, preventing the client thread from hanging forever, waiting for a response that will never come. I grant that this should be configurable, and it was something I'd planned to implement when necessary (as figuring out how to inject that value was kind of a mess).

Is this having an impact on your use of zookeeper? What are your min/maxSessionTimeout values?


slyphon commented Nov 1, 2012

Oh, the other reason for hard-coding the session timeout value was for MRI/JRuby compatibility (granted, kind of the easy way out)

@ghost ghost assigned slyphon Nov 1, 2012

NeMO84 commented Nov 2, 2012

I see. I agree with you that there should definitely be a default. It would just be nice for cases where the server side has been changed due to performance reasons.

We have noticed more occurrences of the Continuation Timeout Error which has had a direct impact of the usage of zookeeper. But I think I am going to spend time in understanding why the server takes so long to respond. This may be due to the server being on a less resourceful machine or maybe even network traffic (I hope the former). Will update with my findings.

Thanks for the prompt response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment