Description
Investigating a client issue I spotted that the CB server node sometimes still had 11210 connections open even though a .NET test application had cleanly terminated.
Instrumentation of SocketPool.cs showed that there was unreliable clean-up of the sockets and this was tracked down to the lack of a destructor/dispose path from CouchbaseClient.
The instrumentation added "print" statements to the socket creation and socket deletion paths. Even with explicit GC.collect calls the deletion prints were very unreliable. I.e. 30 socket created, but variable amounts get closed, sometimes even none.
A simple patch is soon to be uploaded which made a significant difference to the deletion print statements and has been tested using a simple test program. With the patch I saw reliable socket closure. E.g. 30 created, 30 deleted/closed.
Attached to this are.
1) Test program (Program2.cs) which creates CouchbaseClient, allows objects to become out-of-scope and exits cleanly.
2) A patch against CouchbaseClient.cs which drives the destruction path to Dispose the Pool (to be committed).
Without my CouchbaseClient fix I would see the number of sockets created frequently be more than the count of items disposed.
(need to figure out how to push code to gerrit??)