Mamun -
Sorry for the delay in getting back to this issue. I was pulled off onto other things and have only been able to get back to this in the last few days.
Regarding the Memory Leak
1) I have determined that the memory leak is a result of not calling Dispose on your instances of NationalInstruments.NetworkVariable.WebForms.NetworkVariableDataSource. This is what I speculated was the likely cause of the leak when I responded in October. The current implementation of NetworkVariableDataSource requires that it be disposed to clean up some infrastructure that is used to establish and restore connections.
I was able to make some relatively simple modifications to your code to fix the memory leak. I ran your web application overnight to confirm that memory consumption held steady. The attached FixToDisposeNVDataSource.zip file includes the files that I changed. Search for "drohacek" (no quotes) to find my changes. My changes do the following:
- Ensure only one instance of NetworkVariableDataSource is created for each page post back
- Store the NetworkVariableDataSource in session state
- On Page_Unload, pull the NetworkVariableDataSoure out of session state (null the session variable) and call Dispose
2) It looked to me like you were trying to cache the NetworkVariableDataSource across postbacks, by storing it in session state. In the debugger, it looked to me like this was not working properly and that you actually created multiple duplicate instances of NetworkVariableDataSource and NetworkVariableBinding. You might want to debug this part of your code to ensure it is working as you expect.
3) It is not necessary to cache instances of NetworkVariableDataSource across post backs. Our internal implementation caches the underlying network variable connection. It is the creation of this connection that is an expensive operation and we take care of this for you.
Regarding The Behavior When You Delete A Variable
4) Is the behavior a problem for you that you cannot work around? If we change this, it could break other users' programs that rely on this behavior.
Regarding The Client CPU Usage
5) I see iexplorer.exe CPU utilization at ~20%; the difference could be a function of the machines we are running on. You have a lot of UpdatePanel controls in your application. You have more than one timer and you are using the Measurement Studio AutoRefresh control. This means that you are doing a lot of asynchronous posting back to the server and updating of your UI. It is not surprising to me that this consumes a lot of resources. Do you have any reason to believe that it is NIs controls, in particular, that are causing unecessary client-side CPU usage? This would surprise me because the MStudio controls (other than AutoRefresh) are fairly simple in terms of client-side functionality.
I hope that all of this hasn't come too late to be of use to you in your project and I look forward to your response.
David Rohacek
National Instruments
