カスタム スケジューリング アプリケーション (マスターの役割) を Microsoft Exchange Server 2010/2007 (スレーブの役割) と同期できるようにするソフトウェアを開発しています。当社のソリューションは、.NET 4.0、EWS マネージ API、Parallel Fx、そしてもちろん独自の C# コードに基づいています。「ExchangeService」クラスのインスタンスは複数のスレッドで同時に使用されず、インスタンスの総数に関して保守的であるという事実に特に注意を払いました (現在、常に 10 個のライブ インスタンスがあります)。ただし、多くの呼び出しを行います (FindItems、CreateItems、UpdateItems、DeleteItems、LoadPropertiesForItems)。
さらに掘り下げてみると、このアプローチではあまりメリットがないことがわかりました。操作が発行されるたびに、新しい HttpWebRequest が作成され、実行され、閉じられます。認証された要求 (この場合: https + WebCredentials) の場合、基礎となる tcp 接続が TIME_WAIT の状態で OS に返されるようです (この記事で説明されているように: 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 マネージ API が HttpWebRequest (または System.Net のさらに深い部分) を使用する方法に関係していると思います。msdn.microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionssharing.aspx と msdn.microsoft.com/en-us/library/6y3d5dts.aspx をいじりたいと思っていましたが、すべて EWS マネージ API内部または密閉されていると、これを拡張/試すことが難しくなります。
進め方のアドバイス大歓迎！