Python 3 asyncio how to properly close client connection

Question

I have discovered a memory leak in a tornado web app and I'm not sure how to fix it. After some memory profiling I've found that my memcached client is leaking dict's when closing client connections. I open / close memcached clients a lot (once per minute to be specific) as part of an auto-discovery mechanism w/ AWS ElastiCache .

Here is a minimal reproducer using pympler to demonstrate the leak:

from pympler import muppy, summary
import asyncio
import aiomcache

loop = asyncio.get_event_loop()

async def hello_aiomcache():
    mc = aiomcache.Client("127.0.0.1", 11211, loop=loop)
    await mc.set(b"some_key", b"Some value")
    value = await mc.get(b"some_key")
    print(value)
    values = await mc.multi_get(b"some_key", b"other_key")
    print(values)
    await mc.delete(b"another_key")
    mc.close()  

# establish a baseline (watch the <class 'dict line)
summary.print_(summary.summarize(muppy.get_objects()))

for i in range(50):
    loop.run_until_complete(hello_aiomcache())

# <class 'dict grows
summary.print_(summary.summarize(muppy.get_objects()))

ds = [ao for ao in muppy.get_objects() if isinstance(ao, dict)]

# leaked dict looks like {'_loop': <_UnixSelectorEventLoop running=False closed=False debug=False>, '_paused': False, '_drain_waiter': None, '_connection_lost': False, '_stream_reader': <StreamReader t=<_SelectorSocketTransport fd=34 read=polling write=<idle, bufsize=0>>>, '_stream_writer': None, '_client_connected_cb': None, '_over_ssl': False}
ds[2364]

It looks like these dict's will hang around forever until loop.close() is called. I'm confused by this. I think I don't want to ever close the loop that I borrowed from tornado via tornado.ioloop.IOLoop.IOLoop.current().asyncio_loop . Is there any other way to properly close / cleanup these connections without closing the loop?

Answer 1

The problem was caused by not await ing mc.close() .

I was a little surprised to find out that a coroutine won't actually run without some explicit scheduling. I naively thought it would just eventually get called at some point in the future. However, the coroutine docs explicitly state:

Calling a coroutine does not start its code running – the coroutine object returned by the call doesn't do anything until you schedule its execution. There are two basic ways to start it running: call await coroutine or yield from coroutine from another coroutine (assuming the other coroutine is already running!), or schedule its execution using the ensure_future() function or the AbstractEventLoop.create_task() method.