Beaker's pylibmc extension never relinquishes its thread connections

[jwmerrill]

pylibmc's documentation on ThreadMappedPool specifies

You must be sure to call ThreadMappedPool.relinquish() before exiting a thread that has used the pool, from that thread! Otherwise, some clients will never be reclaimed and you will have stale, useless connections.

Beaker's memcached extension creates a ThreadMappedPool

https://github.com/bbangert/beaker/blob/95cf84aff9242a86fdfced1cf9747bbe6fdc4029/beaker/ext/memcached.py#L179

but I couldn't find anywhere where "relinquish" is ever called.

Is there some reason that beaker's use of ThreadMappedPool doesn't require ever relinquishing its connections?

[amol-]

Please note that I never used the pylibmc backend so I haven't tested this, but it looks to me that you are theoretically right but it shouldn't lead to any memory leak in common use cases.

The ThreadMappedPool.relinquish() is not used to release connections back into the pool as that is already done by reserve. It's instead used to totally delete those connections when you are not going to need them anymore.

As you usually serve your application in a thread pool the threads are there for the whole app life-time, so you are going to reuse the same connections over and over and as your threads only die when you actually stop the app you would need to call relinquish only then.

So for apps that are served in a threadpool, which is usually the case, this shouldn't lead to any memory leak. It will by the way lead to memory leaks for apps that start a new thread for each request.

The issue is that as far as I know there is no way to tell a NamespaceManager that a a request finished, so there is no proper place in Beaker where pool.relinquish should be called.