Client seems to be leaking connections after timeouts calling a non responsive memcached server about folsom

[spkrka]

Thank you for the report! I don't have much time to look into in detail right now, but I'd like to understand more about why the connections aren't closed before adding bandaids (hopefully the underlying bug can be fixed instead).

Is this a minimal test? I don't quite understand why you need two memcached instances. I guess you moving the servers to the background will timeout requests to the memcached, so folsom should close and retry, and somewhere at this point one or more of the connections is not properly closed.

[eranharel]

Sorry for the late response, I wanted to have something useful to add to this report...

It turns out my initial test doesn't recreate the bug :(
I tested it with the previous folsom version by mistake. Once I upgraded the test doesn't recreate the bug.

How ever, in production I see a growing number of com.spotify.folsom.client.DefaultRawMemcacheClient instances when the connection count increases when I produce a class histogram.
I read the code several times and it seems to be correct, but I may mistaken, or maybe the channel.close() doesn't complete for some reason.

I took several heap dumps, and will try to analyse tomorrow once the download completes.

[spkrka]

Interesting, I am not sure if that's a leak or if it's simply that the GC doesn't think it's important to collect them just yet.

[eranharel]

Closed as it turns out we were working with the 0.7.1 client, even though I was sure we worked with the latest...
Sorry if this wasted anyone's time :(