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

_poll_timeout isn't documented #56

Open
patricklaw opened this issue Sep 12, 2011 · 4 comments
Open

_poll_timeout isn't documented #56

patricklaw opened this issue Sep 12, 2011 · 4 comments

Comments

@patricklaw
Copy link

We recently had an issue where a piece of code on our network (not pylibmc, something in Java) was leaking client connections to memcached. As a result, memcached eventually ran out of open connections (as per the max connections option, -c). This result was expected, however in our code pylibmc's client behavior was not. In particular, once the server has reached the max connections, when we try to use one of our clients to connect to the server, the connect_timeout behavior does not behave as expected.

For example, if the memcached server's max connection limit has already been hit and we do the following:

c = pylibmc.Client(['our_server'], behaviors={'no_block': True, 'connect_timeout': 50})
ret = c.get('foo')

ret will eventually be given the value None (without any exception ever being raised), but the call will block the process for a long time (five seconds) before giving up. We thought that connect_timeout controlled this behavior, but after inspecting the behaviors dictionary and playing with available options, we found that in fact _poll_timeout controls this behavior. So the behavior we want (approximately) would be given by:

c = pylibmc.Client(['our_server'], behaviors={'no_block': True, '_poll_timeout': 50})
ret = c.get('foo')

This still returns None (which is okay, though an exception would be preferred), but it at least does it within a reasonable amount of time (50ms).

Is there any reason that the _poll_timeout parameter isn't documented in pylibmc? If so, should we be wary of using it? Finally, what exactly does the connect_timeout parameter control?

@lericson
Copy link
Owner

The reason is that poll_timeout is a somewhat weird behavior, as is connect_timeout apparently. The proper course of action here is unclear; the timeouts are pretty hard to configure as it stands.

Here is what the libmemcached man pages have to say about the poll timeout,

MEMCACHED_BEHAVIOR_POLL_TIMEOUT

Modify the timeout value that is used by poll(). The default value is -1.
An signed int pointer must be passed to memcached_behavior_set() to
change this value. For memcached_behavior_get() a signed int value
will be cast and returned as the unsigned long long.

You should be wary of using it as it's not considered part of the API yet.

@patricklaw
Copy link
Author

Okay, thanks for the help! I also noticed that using binary=True causes _poll_timeout to be ignored (in fact, it seems that it will hang indefinitely, not just for 5 seconds)

@lericson
Copy link
Owner

I wish the libmemcached people were told about this rather than me, I think a discussion with Brian Aker would be more fruitful if you get ahold of him.

@jbergstroem
Copy link
Contributor

The best way to communicate with upstream is by using their launchpad: http://launchpad.net/libmemcached

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