EWS Managed API 1.1 - Pull Subscriptions Memory Leak

Question

Has anyone else discovered a memory leak issue with Pull Subscriptions (ExchangeService.SubscribeToPullNotifications()) in Exchange Managed Web Services API? When calling PullSubscription.GetEvents() the memory utilization climbs 4K with nearly every polling call. The only way I've been able to keep the memory utilization down is by forcing garbage collection (via GC.Collect()) after every call - an unnecessary path.

I am surprised to see the API hasn't changed for almost a year.

Rosetta

Keep on doing the GC.Collect() - it is Ok as the Exchange API call masks the time used by the garbage collector. It is quite possible that you have a leak in your code however. – Mess

I ruled out the code leak by creating a simple console app that only creates a single subscription and polls it in a while(true) after 5 seconds of delay. However - the memory keeps climbing (especially when you have multiple subscriptions). – Rosetta

Answer 1

This issue was resolved by another post. Essentially EWS was conflicting with another component that failed to release a NetworkStream (due to a SqlException). ANTS memory profiler was used to pinpoint the cause and timing of the issue. Without this profiling tool we would have never discovered the problem.

Rosetta

Answer 2

I would say that if a GC.Collect reclaims the memory, there is no memory leak. There is just not pressure on the GC to perform a GC collection, since enough memory is available.

Anaesthesiology