Memory Leaks in eOne.SmartConnect.WindowsService.exe
Version 20.17.0.17
We’re running across all kinds of problems keeping the eOne.SmartConnect.WindowsService running over long periods of times. A clean start of the service uses just over 100 MB of RAM but I can watch its usage grow steadily over the course of a week to well over 1 GB of RAM. Judging from some other posts on the forum, I’m not the only one who finds this service to be extremely unreliable. I had a quick look at the code and found a MailMessage object that isn’t disposed of, but I don’t think that this is the problem since there are no attachments to the MailMessage which would be the primary reason for disposing of it. Someone at eOne please take a look at the code with a memory profiler and figure out what’s up. I’m almost certain that if you set a scheduled map to run ever couple of minutes (3, for us) you’ll see this issue.
We’re running across all kinds of problems keeping the eOne.SmartConnect.WindowsService running over long periods of times. A clean start of the service uses just over 100 MB of RAM but I can watch its usage grow steadily over the course of a week to well over 1 GB of RAM. Judging from some other posts on the forum, I’m not the only one who finds this service to be extremely unreliable. I had a quick look at the code and found a MailMessage object that isn’t disposed of, but I don’t think that this is the problem since there are no attachments to the MailMessage which would be the primary reason for disposing of it. Someone at eOne please take a look at the code with a memory profiler and figure out what’s up. I’m almost certain that if you set a scheduled map to run ever couple of minutes (3, for us) you’ll see this issue.
Phil, thank you for the message. We have our development team reviewing this issue. While we are working through this process we would recommend upgrading to the latest version of SmartConnect version 20.18.0.9 as we have done some work around memory issues.
Here is an article written to restart the service on a scheduled basis while we work on resolving the memory leak.,
https://www.eonesolutions.com/restart-smartconnect-scheduling-service-using-batch-file/
Thanks for the quick response. I just checked my server again after a window when no maps were scheduled to run and the service has grown to use over 300 MB of RAM over the course of 2 days.
I appreciate the link to the workaround, but it seems so silly to me to have an actual knowledgebase article about how to schedule restarts for a windows service when the whole purpose of building something as a windows service is to get that long-running functionality. Using the task scheduler to schedule batch restarts is just not going to be acceptable for us so I’ll wait to see what the devs find in regards to the memory leak. I can tell they’ve been chasing after these leaks in the past because there’s some funky forced garbage collection going on in CheckSessionFactory(). Any idea how to turn on the debug logging that writes to the Logs folder? Does that have to be done at the time of installation?
to turn on the logs
1. create Logs folder in your smartconnect folder
2. add a new key in the AppSettings section
restart the service
That did the trick, thanks!
I just ran perfmon for a few hours with debugging on and it’s very clear that the issue resides in the CheckSessionFactory() code. My RAM usage steps up from by about 50 MB every time it tries to refresh the session. I don’t have the ability to debug this code, nor is my perfmon capturing granular enough samples to pinpoint it any further, but if I had to guess I’d say that the Setup.CreateSession(Setup.SetupConnectorPath, connectionString); call just keeps making new sessions without the old ones ever successfully Disposing.
This is where I tap out and eagerly await the release notes for the next version. Good luck!
Has this been resolved? I see in the latest release notes (20.18.0.23) the following note — “SmartConnect Service getting out of memory exception”. Are you confident that the memory leak has been resolved?
This has indeed been resolved. I’ve upgraded to 20.18.0.34 and am no longer experiencing any issues.