You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ok, so this is a wart from the non-evented version, and a kind of a problem that the zkc client poses. The underlying client will go on retrying indefinitely, so in the case that you flubbed your connection string, there would never be an exception. The way the synchronous client works is that it just waits for up to 10 seconds for the connection to enter 'connected' state, and then returns.
Since I have a number of choices here, I'm curious to hear what you think the API should be in this case. Right now, you'd have to actually confirm the connection was in the connected state after this block is called (which I fully admit is sucky and wrong). Should there be a on_connection_timeout? If no callback is registered, then what should the behavior be?
If you're on IRC and would like to discuss, i'm in #zk-gem on irc.freenode.net
Good question. In my use cases if I lose connection to zookeeper for too long, I want to take some action (once) and then just keep waiting for connection. This applies both to the connecting state after a disconnect and to the initial connecting.
For example, currently I set a timer in the on_connecting handler that does things after timeout and it's cancelled in the on_connected handler.
So, I guess a on_connection_timeout event would be convenient. If it's not registered, then I would probably want to retry indefinitely, but that would at least be a somewhat non-backwards-compatible change.
What's the path forward here? Is there something perhaps that could be contributed what @tsilen said in regards to having an on_connetion_timeout event handler that's more convenient? The behavior mentioned about the infinite loop polling isn't ideal, but that change would at least match the API expectation from the zkc client.
documented:
However, that block seems to run after some timeout even when there's no zookeeper connection
The text was updated successfully, but these errors were encountered: