SAPServerHost ActionOnServerException memory leak

[Former Member]

I've implemented the recommended code from previous discussions and, since then, have a problem with a memory leak in my C# service (virtual memory has grown to 426M from an original 31M, memory usage is at 132M from an orignal 13M in 2 weeks time). Here is the code I implemented:

	
public class RFCHost:SAP.Connector.SAPServerHost
{
	public override ActionOnServerException OnServerException 
       ( SAP.Connector.SAPServer server , System.Exception e )
	{
		Thread.Sleep(60000); //wait 1 minute before trying.
		return ActionOnServerException.Reconnect; 
	}
}

public class SAPConnectImpl : SAPConnect
{
	public static void process()
	{
		string programID, gwhost, sapgwxx, codepage;
		string command = "";
		const int numberOfServers = 8;
		RFCHost host = new RFCHost();
		SAPConnectImpl server = null;

		// Retrieve SAP connection settings from App.config file
		programID= ConfigurationSettings.AppSettings["programID"];
		gwhost= ConfigurationSettings.AppSettings["gwhost"];
		sapgwxx= ConfigurationSettings.AppSettings["sapgwxx"];
		codepage= ConfigurationSettings.AppSettings["codepage"];

		for(int i = 0; i < numberOfServers; i++)
		{
			server = new SAPConnectImpl
                            (programID, gwhost, sapgwxx, codepage, host);
		}
		try
		{
			host.Start();

		}
		catch(Exception)
		{
			return;
		}

		do
		{
			Thread.Sleep(1);

		}while(command != "Exit");
	}
	public static void startUp()
	{
		Thread messageProcessor = new Thread
                    (new ThreadStart(process));
		messageProcessor.Start();
	}
}

The expectation from this code is that it would recover from a network event or SAP system restart (and it does). My question is, does the Reconnect action close out the previous connection and start a new one, restart the offending connection, or leave the old connection out there and start a new one? What other types of events might trigger the OnServerException and lead to a memory leak?

[reiner_hille-doering · Accepted solution]

One possible explanation for the groth in memory consumption you experience is the fact that the LIBRFC32 (which NCo uses) writes tons of trace information in case of connection loss; AFAIK even if RFC_TRACE is not turned on. Maybe you best open a OSS ticket at component BC-OP-NET-NCO to clearify the details with the NCo runtime developer.

[Former Member · Accepted solution]

I did some additional research and found that I need to call the dispose method for the OdbcCommand object in order for the garbage collector to do its thing. However, this seems to have only minimally resolved my problem as the memory usage continues to grow. I have found that it is happening specifically in production and not in test even though the volume in test is sufficient to replicate the problem. I am having my system services team use some of their tools to try to isolate the problem and will follow up with an OSS note as I get more information.

[Former Member · Accepted solution]

As a follow up, I've found that the librfc32.dll we are using in our testing environment is much newer than the one in production. This is why we only saw the problem in production. Replacing the dll with the newer one resolves the problem for us.