Мы разрабатываем программное обеспечение, которое позволяет нашему приложению пользовательского планирования (главной роли) синхронизироваться с Microsoft Exchange Server 2010/2007 (подчиненная роль). Наше решение основано на .NET 4.0, EWS Managed API и Parallel Fx и, конечно же, нашем собственном коде C #. Мы особо позаботились о том, чтобы экземпляры класса «ExchangeService» не использовались несколькими потоками одновременно и консервативны в отношении общего количества экземпляров (в настоящее время у нас есть 10 живых экземпляров в любой момент времени). Однако мы делаем много вызовов (FindItems, CreateItems, UpdateItems, DeleteItems, LoadPropertiesForItems).
Копая глубже, мы обнаружили, что такой подход не очень-то нам выгоден. Всякий раз, когда выдается операция, создается новый HttpWebRequest, выполняется и закрывается. Для аутентифицированных запросов (в нашем случае: https + WebCredentials) кажется, что базовое tcp-соединение возвращается в ОС с состоянием TIME_WAIT (как описано в этой статье: msdn.microsoft.com/en-us/library/aa560610 ( BTS.10) .aspx) и сидит там, ничего не делая в течение 4 минут (по умолчанию). Мы уже применили предложения в вышеупомянутой статье (дальнейшее обсуждение можно найти здесь: blogs.msdn.com/b/dgorti/archive/2005/09/18/470766.aspx) и сократили время «сидя там» до 30 секунд. Это нормально в тестовой среде, но не в производственной системе, где tcp-соединения являются более дефицитным ресурсом, и наше приложение не единственное, кто их использует.
Я думаю, что проблема связана с тем, как EWS Managed API использует HttpWebRequest (или даже глубже в System.Net). Мы хотели поиграть с msdn.microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionsharing.aspx и msdn.microsoft.com/en-us/library/6y3d5dts.aspx, но так как все в EWS Managed API является внутренним или герметичным, становится трудным расширить / опробовать это.
Советы о том, как поступить, добро пожаловать!