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

[NeMO84]

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]

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]

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

[NeMO84]

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.