Hashtable insert failed. Load factor too high. - a

问题:

We have an ASP.NET 4.0 MVC3 application running on F5 load balanced servers.

We received the exception below. We do not do multi-threading in our web application, but don't know if the F5 load balancing servers could be factoring into the equation. We see where the exception occurs on earlier versions of .NET (Most of the other posts deal with .NET 2.0 and 3.5). Has anyone experienced this issue with .NET 4.0?

The exception rendered the application unusable because upon login no page could be loaded without encountering the exception.

Other links already reviewed:

• 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] FATAL System [(null)] – An unhandled exception occurred in the XYZ application. System.InvalidOperationException: Hashtable insert failed. Load factor too high. The most common cause is multiple threads writing to the Hashtable simultaneously. at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) at System.ComponentModel.TypeDescriptor.NodeFor(Type type, Boolean createDelegator) at System.ComponentModel.TypeDescriptor.GetProvider(Type type) at System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptionProvider..ctor(Type type) at System.Web.Mvc.ModelBinderDictionary.GetBinder(Type modelType, IModelBinder fallbackBinder) at System.Web.Mvc.ControllerActionInvoker.GetModelBinder(ParameterDescriptor parameterDescriptor) at System.Web.Mvc.ControllerActionInvoker.GetParameterValue(ControllerContext controllerContext, ParameterDescriptor parameterDescriptor) at System.Web.Mvc.ControllerActionInvoker.GetParameterValues(ControllerContext controllerContext, ActionDescriptor actionDescriptor) at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) at System.Web.Mvc.Controller.ExecuteCore() at System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext)
at System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.b__5() at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.b__0() at System.Web.Mvc.MvcHandler.<>c__DisplayClasse.b__d() at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

As you can see from the stack trace it does not point to a particular place in our code making it difficult to debug.

Any advice to prevent encountering this exception would be greatly appreciated.

回答1:

This is an uncommon issue but it does happen for many people (me included). It does not seem to be linked with any specific load threshold, it just "happens" and once it does it continues to happen more frequently regardless of the load.
Solutions:
Temporary: Reset IIS and cross your fingers it doesn't happen again
Permanent: Get the patch from microsoft described in the KB article or wait for the next version of .Net where it is going to be fixed (it is reported to already been fixed in 4.5 Beta)

回答2:

Check out Kim's response in this thread: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/172f4f77-601e-4b4f-8d98-582f8f62a98e

---

Hi Matt,

In .NET 2.0, this error is almost always caused by multiple threads modifying the Hashtable at the same time. The fix is to insert locks before modifying the Hashtable, since Hashtable isn't multiple writer threadsafe. Another possible solution is to work with the synchronized wrapper via Hashtable.Synchronized, however we recommend the former for finer control.

So that's the fix if it's your code that's modifying the Hashtable. Based on the info you provided, I think this isn't the case. You mentioned that you're encountering this bug with an ASP 2.0 website, so this could be caused by a downstream Hashtable caller. For example, if the call stack looks something like the following, note that this is a bug that has been fixed for the latest release.

Thanks, Kim

Stack trace: at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) at System.Collections.Hashtable.set_Item(Object key, Object value) at System.ComponentModel.TypeDescriptor.CheckDefaultProvider(Type type) at System.ComponentModel.TypeDescriptor.NodeFor(Type type, Boolean createDelegator) at System.ComponentModel.TypeDescriptor.GetDescriptor(Type type, String typeName) at System.ComponentModel.TypeDescriptor.GetAttributes(Type componentType) at System.Web.UI.ThemeableAttribute.IsTypeThemeable(Type type) at System.Web.UI.Control.ApplySkin(Page page) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)