Nie można wstawić tabeli haasowania. Współczynnik obciążenia jest zbyt wysoki. - asp.NET 4.0 MVC3

Question

Mamy aplikację ASP.NET 4.0 MVC3 działającą na serwerach z obciążeniem F5.

Otrzymaliśmy wyjątek poniżej. Nie robimy wielowątkowości w naszej aplikacji internetowej, ale nie wiemy, czy serwery równoważenia obciążenia F5 mogły uwzględniać to równanie. Widzimy, gdzie występuje wyjątek we wcześniejszych wersjach .NET (Większość innych postów zajmuje się .NET 2.0 i 3.5). Czy ktoś napotkał ten problem z .NET 4.0?

Wyjątek spowodował, że aplikacja stała się bezużyteczna, ponieważ po zalogowaniu nie można załadować strony bez napotkania wyjątku.

Inne linki już opinię:

• Hashtable insert failed. Load factor too high. - ASP.NET 2.0
• HashTable Insert Failed. Load Factor Too High. .NET 2.0 SP2
• Frustrating error in WPF (.NET 4.0) internals: Hashtable insert failed. Load factor too high

2012-02-02 06: 01: 42.671 [26] krytyczny systemu [(null)] - Wystąpił nieobsługiwany wyjątek w aplikacji XYZ. System.InvalidOperationException: Nie można wstawić tabeli haszującej. Współczynnik obciążenia zbyt wysoki. Najczęstszą przyczyną jest jednoczesne pisanie wielu wątków do tablicy . w System.Collections.Hashtable.Insert (klawisz Object, Object, nvalue Boolean ADD) w System.ComponentModel.TypeDescriptor.NodeFor (typ Type, Boolean createDelegator) w System.ComponentModel.TypeDescriptor.GetProvider Type (typ) w System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptionProvider..ctor (typ typ) w System.Web.Mvc.ModelBinderDictionary.GetBinder (typ modelType, IModelBinder fallbackBinder) w System.Web.Mvc.ControllerActionInvoker.GetModelBinder (ParameterDescriptor parameterDescriptor) at System.Web.Mvc.ControllerActionInvoker.GetParameterValue (ControllerContext Kontekst kontrolera, parametr ParameterDescriptor rDescriptor) w System.Web.Mvc.ControllerActionInvoker.GetParameterValues ​​(ControllerContext controllerContext, ActionDescriptor actionDescriptor) w System.Web.Mvc.ControllerActionInvoker.InvokeAction (ControllerContext controllerContext, String ActionName) w System.Web.Mvc.Controller. ExecuteCore() at System.Web.Mvc.ControllerBase.Execute (RequestContext requestContext)
pod adresem System.Web.Mvc.MvcHandler. <> c__DisplayClass6. <> c__DisplayClassb.b__5() pod adresem System.Web.Mvc.Async.AsyncResultWrapper. <> c__DisplayClass1.b__0() pod adresem System.Web.Mvc.MvcHandler. <> c__DisplayClasse.b__d() w System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() w System.Web.HttpApplication.ExecuteStep (etap IExecutionStep, logiczna & completedSynchronously)

Jak widać ze śledzenia stosu, nie wskazuje on konkretnego miejsca w naszym kodzie, co utrudnia debugowanie.

Wszelkie rady zapobiegające temu wyjątkowi zostaną bardzo docenione.

Answer 1

Wyjazd Kima odpowiedź w tym wątku: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/172f4f77-601e-4b4f-8d98-582f8f62a98e

---

Cześć Matt,

W .NET 2.0, błąd ten jest prawie zawsze spowodowane przez wiele wątków modyfikujących Hashtable w tym samym czasie. Poprawka polega na wstawianiu blokad przed modyfikacją HashTable, ponieważ Hashtable nie jest wielosektorowym zabezpieczeniem wątków. Innym możliwym rozwiązaniem jest praca ze zsynchronizowanym opakowaniem za pomocą Hashtable.Synchronized, jednak zalecamy ten pierwszy w celu lepszej kontroli.

To jest poprawka, jeśli to twój kod modyfikuje Hashtable. Na podstawie podanych informacji uważam, że tak nie jest. Wspomniałeś o tym, że napotykasz ten błąd w witrynie ASP 2.0, więc może to być spowodowane przez wywołujący wywołanie Hashtable. Na przykład, jeśli stos wywołań wygląda następująco, zauważ, że jest to błąd, który został naprawiony dla najnowszej wersji.

Dzięki Kim

Ślad stosu: w System.Collections.Hashtable.Insert (klawisz Object, Object, nvalue Boolean ADD) na System.Collections.Hashtable.set_Item (klucz, wartość obiektu Object) w System.ComponentModel.TypeDescriptor.CheckDefaultProvider (typ typ) w System.ComponentModel.TypeDescriptor.NodeFor (typ, typ Boolean createDelegator) w System.ComponentModel.TypeDescriptor.GetDescriptor (typu typ, string typeName) w System.ComponentModel. TypeDescriptor.GetAttributes (Type componentType) at System.Web.UI.ThemeableAttribute.IsTypeThemeab le (Type type) at System.Web.UI.Control.ApplySkin (Strona page) at System.Web.UI.Control.InitRecursive (Control namingContainer) at System.Web.UI.Control.InitRecursive (Control namingContainer) w System.Web.UI.Control.InitRecursive (Control namingContainer) w System.Web.UI.Control.InitRecursive (Control namingContainer) w System.Web.UI.Control.InitRecursive (Control namingContainer) at System.Web .UI.Page.ProcessRequestMain (Boolean includeStainsBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Answer 2

Jest to niezbyt częsty problem, ale dzieje się tak u wielu osób (włącznie z mną). Wygląda na to, że nie jest powiązany z żadnym konkretnym progiem obciążenia, po prostu "dzieje się", a gdy już to zrobi, będzie się dziać częściej, niezależnie od obciążenia.
Solutions:
tymczasowa: Reset IIS i trzymaj kciuki, że nie powtórzy
Permanent: Pobierz patch od Microsoft opisane w KB article lub poczekać na następną wersją .NET gdzie będzie stała (zostało zgłoszone, że zostało już naprawione w wersji 4.5 Beta)