TcpClient/Socket objects disposed but still exist in memory

[sungam3r]

Memory dump of our running app shows something like this:

Both TcpClient and Socket objects have already been disposed, but still in memory referenced by TcpClientAdapter. TcpClientAdapter has private TcpClient / Socket field (depends of rabbitmq-dotnet-client version) which closed (disposed) in TcpClientAdapter.Close() method. We can consider this situation as memory leak with non-growing memory overhead.

It's annoying to have those broken and unused objects (with all inner object trees, e.g. byte arrays or ManualResetEvents) in memory and in profiler reports. These objects prevent from investigation real memory leaks.

Please, consider to break reference to TcpClient / Socket in TcpClientAdapter after Close() call.
Maybe, it's better to break reference a bit higher in call stack, e.g. SocketFrameHandler class.

[kjnilsson]

We can certainly null the socket field in the Close method of TcpClientAdapter. What is the scenario where you are holding onto the Connection object after it has been closed?

[sungam3r]

We use EasyNetQ library and just call RabbitHutch.CreateBus and then Publish / Subscribe methods. App uses 6 RabbitAdvancedBus instances at the same time, serving 6 rpc-request and around 20-40 rpc-response queues.

[sungam3r]

Why do you think that the Connection object has been closed?

[kjnilsson]

If the socket and TcpClientAdaptor have already been disposed why keep the Connection instance around? IIRC EasyNetQ doesn't use the AutorecoveringConnection so not sure what the scenario is where the socket has been disposed but the Connection is still somehow in use.

[sungam3r]

Indeed, connection is closed (m_closed = true). But EasyNetQ really holds reference to Model object, which in turn holds reference to closed Connection.

[sungam3r]

[kjnilsson]

May be worth getting onto the EasyNetQ maintainers and ask them to clean up after connection close.

[sungam3r]

May be, but it is good practice to break clearly known references to dead objects trees in own code. It protects from improper external use (as EasyNetQ does) and reduces memory footprint.

[michaelklishin]

We can do both ;)

On 11 Oct 2016, at 17:22, Ivan Maximov notifications@github.com wrote:

May be, but it is good practice to break clearly known references to dead objects trees in own code. It protects from improper external use (as EasyNetQ does) and reduces memory footprint.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[sungam3r]

Thank you! I will continue to investigate improper memory usage in EasyNetQ code.