SAP .NET Connector 3.0 Memory Leak?

[Former Member]

We have an integration adapter that uses .net connector to talk to SAP. Our adapter runs continuously (as a windows service) periodically connecting/disconnection to SAP. There is an apparent memory leak in .NET connector  - it seems that it never fully releases connection resources and ~100K is kept after every cycle...,

We implement our own IDestinationConfiguration, send RfcConfigurationEventArgs(DELETE) evens to disconnect and even call RfcDestinationManager.RegisterDestinationConfiguration/UnregisterDestinationConfiguration for every cycle and force the GC at the end, but still memory builds up...

We tried using different versions of the connector : patch 7, Patch 9 and the latest Patch 11 - all the same.

Has anybody experience the same thing?

As much as I dislike when the control of the connection management is taken away - I dislike even more when such important integration layer (nCo) is release without all scenario tested... so the question to SAP : did you guys ever tested the connector for continuous operation ?

Thanks,

Jon

[MarkusTolksdorf]

Hi Jon,

we are not aware of a memory leak. Please open a message with detailed information about the use case.

Best regards,

Markus

[Former Member]

Markus,

Here are more details, let me know if you need more specifics:

It seems to be related to threading - if we open/close connections using the same single thread, sequentially, not significant memory leakage occur. However, when we span new threads to handle additional connections, the leakage gets noticeable and constant.

The multithreading mechanism works like this:

When the Windows service starts the next cycle (it is a timer initiated thread)

- the main thread issues RfcDestinationManager.RegisterDestinationConfiguration, itself serving as a singleton IDestinationConfiguration implementation

-- for each configured SAP system (may be many) a new thread is started

--- in each "SAP system" thread one or more threads are started that open individual connections to the SAP system, only the first for the system creates the new destination, the rest using the same destination name.

-- "SAP system" thread waits for all child threads to complete before   generating ConfigurationChangeHandler(DELETE) event, thus closing all open connections to the SAP system and removing the Destination configuration.

- waits for all "SAP system" threads to complete before issuing  RfcDestinationManager.UnregisterDestinationConfiguration, Force Garbage Collection at the end.

That completes the cycle. When the timer expires (~30-60 seconds) the new cycle is started - new thread ... the cycle thread is using the locking mechanism to prevent two instances running at the same time.

We tried two approaches - keeping the IDestinationConfiguration implementation static and only issuing  RegisterDestinationConfiguration (without UnregisterDestinationConfiguration) or as described above doing it for every cycle - does not make any difference. The leakage is hard to estimate precisely due to  the GC, but based on 60 second interval and 2 SAP systems with 4 connection threads each the estimate is about 1 MB /hour

Thanks,

Jon

[MarkusTolksdorf]

Hello Jon,

You don't have to fire a DELETE event, if you plan to use the same destination later again. Thus you will lose the benefit of connection pooling that will ensure that open connections are re-used if possible. The IDestinationConfiguraiton should be registered once - not again and again. Unregistering it is only thought in case there is a need to switch the implementation or when shutting down the whole runtime environment. However, all of this should not lead to a memory leak. Please open a ticket on BC-MID-CON-NCO so that further investigations can be done.

Best regards,

Markus

[Former Member]

Markus,

The DELETE is deliberate - we don't need the pooling  - it would be a good option for the NCo to offer non-pooled connections with an explicit lifecyle.

Not sure how I can open a ticket, we don't have  an SAP Service account is there another way?

Thanks,

Jon

[MarkusTolksdorf]

Hi Jon,

actually, it is possible to do this by configuring pool size to 0 and using destinations with a context in the current session. However, pooling has many benefits. Therefore you should make use of it.

Without being a customer or a partner, you cannot open a ticket, I'm sorry. However, somehow you must have been able do get the connector from the download page. With that user you should be able to create a ticket.

Best regards,

Markus

[Former Member]

Just an update, we opened a ticket with SAP...and after a few weeks - it is confirmed - there is a memory leak in .Net connector when used in multithreaded environment (the pool hold on to a dead application thread preventing it to be GCed).

Thanks,

Jon

[Former Member]

Hi Jon and Markus, what was the solution to the memory leak? Is there a fix? Has a newer version of the connector been released? Thanks Dean

[MarkusTolksdorf]

Hi Dean,

in the latest patch level of NCo, which is 3.0.12, this multi-threading memory leak has been fixed.

Best regards,

Markus