Memory Leak in .Net SDK

[sagarok]

🐛 Memory Leak: LSEG .Net SDK objects not released after OmmConsumer uninitialization

Description

We are using Refinitiv .Net SDK in a service built on ASP.NET Core.
Following the examples provided, we create an OmmConsumer, subscribe to approximately 30,000 snapshot datapoints, and register a client to process incoming messages.

After all datapoints are received and processed, we uninitialize the consumer and all created objects were disposed. These objects are properly garbage collected and removed from memory.

However, a large number of internal objects from the LSEG.* namespaces remain in memory and are not garbage collected.

This process is repeated multiple times in response to incoming requests from an API endpoint. After each operation, the amount of memory occupied by LSEG.* objects increases significantly and is never freed, suggesting a potential memory leak within the SDK.

---

Steps to Reproduce

1. Create an OmmConsumer following the SDK examples.
2. Subscribe to ~30,000 snapshot datapoints.
3. Process all received messages.
4. Uninitialize the consumer and dispose of all created objects.
5. Monitor memory usage before and after each iteration.

---

Expected Behavior

All resources associated with OmmConsumer and related LSEG.* objects should be released after uninitialization, allowing memory to be reclaimed by the garbage collector.

---

Actual Behavior

Memory usage continues to grow after each operation.
LSEG.* objects remain in memory and are not collected by the GC, resulting in continuously increasing memory consumption.

---

Environment

"LSEG.Eta.Core" Version="3.4.0"
"LSEG.Eta.ValueAdd" Version="3.4.0"
"LSEG.Eta.Ansi" Version="3.4.0"
"LSEG.Eta.AnsiPage" Version="3.4.0"
"LSEG.Ema.Core" Version="3.4.0"

• SDK version: 3.4.0
• **.NET version: 9

[V-Anyakin]

@sagarok Thank you for raising this issue and the information provided. We created an internal ticket to investigate it.

[soranat]

There are object pools per OmmConsumer instance and global object pools for the entire process which can be reused to improve the performance of the RTSDK C# library. The objects that are not collected by GC are a part of global pools which can be reused by multiple OmmConsumer instances.

I tested with your scenarios and .NET memory usage per iteration is not increased significantly from the memory usage graph below.

Furthermore, you can tune memory usage per OmmConsumer using the ItemCountHint configuration parameter to set number of request items to override the default 100K items. The following is the same EMA file configuration for Consumer_2.

           <Consumer>
			<Name value="Consumer_2"/>

			<!-- ChannelSet specifies an ordered list of Channels to which OmmConsumer will attempt to	-->
			<!-- connect, one at a time, if the previous one fails to connect							-->
			<ChannelSet value="Channel_1, Channel_2"/>

			<Logger value="Logger_2"/>
			<Dictionary value="Dictionary_2"/>
			<XmlTraceToStdout value="0"/>
			**<ItemCountHint value="30000"/>**
		</Consumer>

Also, I attached the source code for this testing.

Consumer.zip

[sagarok]

@soranat
Thank you for the information, especially the configuration hint:

<ItemCountHint value="30000"/>

Regarding your results, which tool are you using to collect memory statistics?
I’m seeing a very different picture on my side when using the Visual Studio Performance Profiler and Diagnostic Tools.

Besides the significant increase in memory usage after each round, you can also see that our manually created objects are still being held by the LSEG objects, even after a thorough garbage collection.