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
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?
The text was updated successfully, but these errors were encountered:
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.
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)
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.
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, theconnect_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:
ret
will eventually be given the valueNone
(without any exception ever being raised), but the call will block the process for a long time (five seconds) before giving up. We thought thatconnect_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: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 theconnect_timeout
parameter control?The text was updated successfully, but these errors were encountered: