The connector that I'm working on started having this issue recently with System.OutOfMemoryException
All the code does is parse an XML response using the Linq XDocument.
Here are the server specs
Running dataminer (10.3.11.0-13456)
Hi Geovanny,
Please remember that SLScripting is a 32-bit process and is limited to 4GB of memory.
Consider the amount of memory you need to process your responses, assuming you have the original response in memory as a string, XDocument will double the required memory for its model.
For example, a 1MB large document in UTF-8 (the common encoding used in communication), it will be 2MB in .NET which uses the UTF-16 encoding for strings in memory. Duplicating that for XDocument gives you a total of 4MB consumed to process your response.
On top of that, your stack trace is pointing at a SetParameters call. It's currently marshalling your data from managed .NET to unmanaged C++ memory. This means your data gets copied again. So assuming you roughly have 2MB of data to set, you need to add another copy totalling at 6MB having been consumed if your original response string and XDocument are still held within the same scope.
If your responses are not large enough to reach into gigabytes this way, check if your code is retaining information longer than it should. Are you correctly disposing of items that should be disposed?
There are tools like the visual studio debugger and dotMemory to analyse the managed memory (.NET) in use. Not having any other active protocols or elements can make this analysis a lot easier.
One more thing that might explain the exception you see is the amount of data you are trying to set in a single SetParameters call. If you are reaching into millions of values or gigabytes of memory, the inter-process communication can have trouble with the shared memory and you should consider using multiple requests as long as SLScripting is 32-bit.
I know the best practice is to use as few Notify requests as possible, which is generally true when compared to setting values one-by-one and thus losing a lot of time on moving between processes compared to the cost of SLProtocol handling a single value. At some point though, the cost of notifying SLProtocol will be minimal compared to SLProtocol processing a million values, and splitting the data into manageable chunks will not noticeably slow things down.
Hi Geovanni,
Without more context or seeing code it's difficult to say what could be causing the out of memory exception.
Are objects being added to collections (list, dictionary, ...)? If that's the case make sure they are not endlessly growing.
The SLScripting process is also being shared by other elements on the same DMA, so it could be that the problem is actually caused by another element that takes almost all memory. Parsing a bigger amount of data in your connector could then cause the OutOfMemoryException in your connector.
To investigate this further you could take a memory dump of the process. With specific tools it's then possible to see what exactly is being stored in memory.