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

connect block is called after a while even if no connection is available #3

Open
tsilen opened this issue Jul 23, 2012 · 3 comments
Open
Assignees

Comments

@tsilen
Copy link

tsilen commented Jul 23, 2012

documented:

zkem.connect do
  # the client is connected when this block is called
end

However, that block seems to run after some timeout even when there's no zookeeper connection

@slyphon
Copy link
Contributor

slyphon commented Jul 23, 2012

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

@ghost ghost assigned slyphon Jul 23, 2012
@tsilen
Copy link
Author

tsilen commented Jul 25, 2012

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.

@johnbellone
Copy link

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.

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

3 participants