Не удалось вставить хэш-таблицу. Коэффициент загрузки слишком высокий. - asp.NET 4.0 MVC3

У нас есть приложение ASP.NET 4.0 MVC3, работающее на серверах F5 с балансировкой нагрузки.

Мы получили исключение ниже. Мы не занимаемся многопоточностью в нашем веб-приложении, но не знаем, могут ли серверы балансировки нагрузки F5 учесть это уравнение. Мы видим, где происходит исключение в более ранних версиях .NET (большинство других публикаций имеют дело с .NET 2.0 и 3.5). Кто-нибудь испытывал эту проблему с .NET 4.0?

Исключение сделало приложение непригодным для использования, поскольку при входе в систему ни одна страница не могла быть загружена без возникновения исключения.

Другие ссылки уже рассмотрены:

Не удалось вставить хэш-таблицу. Коэффициент загрузки слишком высокий. - ASP.NET 2.0Ошибка вставки HashTable. Коэффициент загрузки слишком высок. .NET 2.0 SP2Разочаровывающая ошибка в WPF (.NET 4.0): Ошибка вставки хэш-таблицы. Коэффициент загрузки слишком высокий

2012-02-02 06: 01: 42,671 [26] FATAL System [(null)] - Произошло необработанное исключение в приложении XYZ. System.InvalidOperationException: сбой вставки хэш-таблицы. Коэффициент загрузки слишком высокий. Наиболее распространенной причиной является одновременная запись нескольких потоков в Hashtable. в System.Collections.Hashtable.Insert (ключ объекта, Object nvalue, логическое добавление) в System.ComponentModel.TypeDescriptor.NodeFor (тип type, Boolean createDelegator) в System.ComponentModel.TypeDescriptor.GetProvider (тип type) в System.Com. DataAnnotations.AssociatedMetadataTypeTypeDescriptionProvider..ctor (Type type) в System.Web.Mvc.ModelBinderDictionary.GetBinder (Тип modelType, IModelBinder fallbackBinder) в System.Web.Mvc.ControllerActionInes.SetInescript. GetParameterValue (ControllerContext controllerContext, ParameterDescriptor parameterDescriptor) в System.Web.Mvc.ControllerActionInvoker.GetParameterValues (ControllerContext controllerContext, ActionDescriptor actionDescriptor) в системном.Web.Mvc.Controller.ConvisionIntectionController-ролике-роликеПредприятия_контроле .ExecuteCore () в System.Web.Mvc.ControllerBase.Execute (RequestCont ext requestContext)
в System.Web.Mvc.MvcHandler. <> c__DisplayClass6. <> c__DisplayClassb.b__5 () в System.Web.Mvc.Async.AsyncResultWrapper. <> c__DisplayClass1.b__0 () в System.Web.Mvc.MvcHisler>. .b__d () на System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute () на System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep, логический и завершенный синхронно)

Как вы можете видеть из трассировки стека, он не указывает на конкретное место в нашем коде, что затрудняет его отладку.

Любой совет, чтобы предотвратить возникновение этого исключения будет принята с благодарностью.

 Nick Bork02 февр. 2012 г., 16:04
Было бы полезно указать «когда пользователь загружает страницу»
 SLaks02 февр. 2012 г., 16:01
@ Splash-X: вся трассировка стека находится в коде фреймворка.
 Nick Bork02 февр. 2012 г., 16:41
Эта ошибка возникает при каждом запросе с момента запуска пула приложений или после того, как пул приложений был активен в течение определенного периода времени? Есть ли конкретная нагрузка трехпроходная (общее количество запросов или запросов в секунду?), Которая ее вызывает? Можете ли вы дать нам больше информации о вашей модели, которую вы пытаетесь связать в своем действии? Внутренне метод NodeFor использует WeakHashTable. Он использует блокировку таблицы при добавлении нового элемента.
 Nick Bork02 февр. 2012 г., 15:57
Вы пытались заблокировать хеш-таблицу, выполнить свои действия, а затем разблокировать ее? Первый пример под примечаниями:msdn.microsoft.com/en-us/library/...
 Chris Shouts02 февр. 2012 г., 16:46
Ты виделэтот блог?

Ответы на вопрос(2)

http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/172f4f77-601e-4b4f-8d98-582f8f62a98e

Привет Мэтт,

В .NET 2.0 эта ошибка почти всегда вызвана одновременным изменением Hashtable несколькими потоками. Исправление заключается в вставке блокировок перед изменением Hashtable, поскольку Hashtable не поддерживает многопотоковую запись. Другим возможным решением является работа с синхронизированной оболочкой через Hashtable.Synchronized, однако мы рекомендуем первую для более точного управления.

Так что это исправление, если ваш код изменяет Hashtable. На основании предоставленной вами информации, я думаю, что это не так. Вы упомянули, что вы столкнулись с этой ошибкой на веб-сайте ASP 2.0, так что это может быть вызвано вызывающим абонентом Hashtable. Например, если стек вызовов выглядит примерно так, обратите внимание, что это ошибка, исправленная в последней версии.

Спасибо Ким

Трассировка стека: в System.Collections.Hashtable.Insert (ключ объекта, значение объекта, логическое добавление) в System.Collections.Hashtable.set_Item (ключ объекта, значение объекта) в System.ComponentModel.TypeDescriptor.CheckDefaultProvider (Type type) в системе .ComponentModel. (Введите тип) в System.Web.UI.Control.ApplySkin (Страница страницы) в System.Web.UI.Control.InitRecursive (Control namingContainer) в System.Web.UI.Control.InitRecursive (Control namingContainer) в System.Web .UI.Control.InitRecursive (Control namingContainer) в System.Web.UI.Control.InitRecursive (Control namingContainer) в System.Web.UI.Control.InitRecursive (Control namingContainer) в System.Web.UI.Page.ProcessRequestMain (Boolean). includeStagesBeforeAsyncPoint, Boolean includeStage sAfterAsyncPoint)

но она случается со многими людьми (включая меня). Похоже, он не связан с каким-либо определенным порогом нагрузки, он просто «случается», и если это происходит, он продолжает происходить чаще, независимо от нагрузки.
Решения:
Временно: сбросьте IIS и скрестите пальцы, это больше не повторится
Постоянный: получите исправление от Microsoft, описанное вСтатья кб или дождитесь следующей версии .Net, где она будет исправлена (сообщается, что она уже исправлена в 4.5 Beta)

Ваш ответ на вопрос