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

allow_session_lost documentation for ChildWatchers seems #156

Closed
jimfulton opened this issue Jan 3, 2014 · 7 comments
Closed

allow_session_lost documentation for ChildWatchers seems #156

jimfulton opened this issue Jan 3, 2014 · 7 comments

Comments

@jimfulton
Copy link

The documentation says:

"If allow_session_lost is set to True, then the function will no longer be called if the session is lost."

But:

>>> import kazoo.client
>>> c = kazoo.client.KazooClient('localhost:2182')
>>> c2 = kazoo.client.KazooClient('localhost:2183')

I have 2 connections against 2 tunnels.

>>> @c.add_listener
... def _(state):
...     print state
... 
>>> c.start()
CONNECTED
>>> c2.start()
>>> @c.ChildrenWatch('/test', allow_session_lost=True)
... def _(data):
...     print True, data
... 
True [u'b', u'a', u'aa', u'z']
>>> @c.ChildrenWatch('/test', allow_session_lost=False)
... def _(data):
...     print False, data
... 
False [u'b', u'a', u'aa', u'z']

I break the first tunnel

SUSPENDED

Wait a while and recreate it:

LOST
CONNECTED

>>> _ = c2.delete('test/a')
True [u'b', u'aa', u'z']

>>> _ = c2.create('test/a')
True [u'b', u'a', u'aa', u'z']

Note that the session is lost when allow_session_lost is false, not when is True. Is this a bug? doc bug?

@bbangert
Copy link
Member

bbangert commented Jan 3, 2014

I'm going to guess at the moment that its a bug, as I didn't go through it again when refactoring DataWatch recently and it did several things like DataWatch did (incorrectly) at first.

@jimfulton
Copy link
Author

So, from #157 it appears that allow_session_lost should be treated as deprecated and ignored. The current default behavior for both DataWatch and ChildrenWatch is to restore watches to new sessions. This is what I want. I was thrown by the documentation, which suggests otherwise.

For my use case, I should simply not pass allow_session_lost.

WRT documentation, I suggest removing mention of allow_session_lost, and saying that watches are restored.

I also suggest that deprecation warnings be issued if allow_session_lost is used.

If you agree, I'll make a pull request.

@bbangert
Copy link
Member

bbangert commented Jan 4, 2014

Yep, that sounds good to me.

@bbangert
Copy link
Member

Was there a pull request ever made? ;)

@jimfulton
Copy link
Author

I don't remember. I guess not. Sorry.

@bbangert
Copy link
Member

bbangert commented Jun 1, 2017

Closing this as I'm not sure if it's still an issue. Changes have been made, etc. Watchers now restore on reconnect as well which could alter this.

@bbangert bbangert closed this as completed Jun 1, 2017
@l2dy
Copy link

l2dy commented Nov 7, 2019

Closing this as I'm not sure if it's still an issue. Changes have been made, etc. Watchers now restore on reconnect as well which could alter this.

The documentation suggests that if allow_session_lost is set to True, the function will no longer be called if the session is lost. However, the test_child_stop_on_session_loss test in test_watchers.py expects that it won't be called when allow_session_lost is set to False after session loss. Which is the expected behavior?

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

No branches or pull requests

3 participants