爲什麼DirectoryEntry屬性返回需要10個小時？

-1

我們正在通過一個測試廣告中的成千上萬個用戶列舉。整件事可以在大約一個小時內運行。但是有時候，對於單個用戶來說，以下幾行代碼將會停留大約10個小時。爲什麼DirectoryEntry屬性返回需要10個小時？

這並不總是會發生，當它發生時，它可能會發生在任何AD用戶身上。

 using (DirectoryEntry de = new DirectoryEntry(String.Format(@"LDAP://{0}/<GUID={1}>", host, objectGUID), admin, password, server.AuthenticationMethod)) 
     { 
      try 
      { 
       dn = (string)de.Properties["distinguishedName"][0]; 
      } 
      catch 
      { 
       // log it... 
      } 
     }

經過長時間的延遲，事情繼續下去，好像沒有什麼是錯的。

什麼可能會導致此延遲？

來源

2015-10-13 x5657

發生這種情況時服務器上還會發生什麼？ – user1666620

沒有什麼看起來很重要。 AD服務器沒有較高的CPU或內存使用量。 NETSTAT不顯示端口耗盡的跡象。客戶端也運行內部ASP.NET網站，但沒有任何稅收。 – x5657

是否在事件查看器中顯示任何錯誤？發生這種情況時，活動目錄是否有任何事件？ – user1666620

TL; DR啓用AuthenticationTypes.Secure來解決這個問題。

我創建了一個能夠根據需要重現此問題的測試應用程序。所有的測試應用程序都是啓動4個線程，每個線程包含一個無限循環。在while循環中，我創建了一個新的DirectoryEntry並在其上調用RefreshCache。很多時候，尤其是在啓動時，一個線程會遇到以下異常

COMException -2147016643 "A decoding error has occurred."

此錯誤也被稱爲0x8007203D又名-2147016643又名2147950653

當這個例外是在一個線程可見，一個或多個其他線程將掛起對RefreshCache的調用。

在DirectoryEntry構造函數中，我們不包括AuthenticationTypes.Secure。 Secure是一個默認標誌，但因爲我們設置了其他AuthenticationTypes標誌，所以我們也應該手動包含Secure。不確定爲什麼，但在安全模式啓用時，DirectoryServices在多線程下表現得非常好。

來源

2015-10-30 16:53:56 x5657

爲什麼DirectoryEntry屬性返回需要10個小時？

回答

相關問題