Memory useage problem with ExceptionCallHandler

Topics: Exception Handling Application Block, Policy Injection Application Block
Sep 7, 2011 at 6:23 AM
Edited Sep 7, 2011 at 6:34 AM

I'm currently seeing excessive memory usage when using the ExceptionCallHandler from EntLib 4.1, it seems to come from the following code in the constructor

ExceptionPolicyFactory policyFactory = new ExceptionPolicyFactory(configurationSource);
exceptionPolicy = policyFactory.Create(exceptionPolicyName);

This causes the all the objects required for the ExceptionPolicyImpl to be rooted via (I think) the LogWriterStructureHolder resulting in a lot of objects hanging around forever eg.

MT        Num items   Tot. size   Type
1240d55c 38085 457020 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SystemConfigurationSource
0e8e335c 3442 562384 System.Byte[]
1281c9e4 38083 609328 Microsoft.Practices.EnterpriseLibrary.Logging.Filters.LogFilterHelper
1281c7bc 38083 609328 Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolderUpdater
1281e0b8 38083 913992 System.Collections.Generic.List`1[[Microsoft.Practices.EnterpriseLibrary.Logging.Filters.ILogFilter, Microsoft.Practices.EnterpriseLibrary.Logging]]
1281bf14 38083 1066324 Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter
12814f3c 38119 1219808 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationChangedEventHandler
1281c6cc 38083 1370988 Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolder
0e8da0f4 38086 1675784 System.Threading.ReaderWriterLock
0e8e2a88 43344 1850072 System.Int32[]
1281e9dc 38083 1980316 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[Microsoft.Practices.EnterpriseLibrary.Logging.LogSource, Microsoft.Practices.EnterpriseLibrary.Logging]]
0e8e08ec 22828 2440792 System.String
7aa3f628 76166 3655968 System.Diagnostics.EventLogTraceListener
12b712f4 76166 4265296 Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener
12b705d8 38116 4724272 System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[Microsoft.Practices.EnterpriseLibrary.Logging.LogSource, Microsoft.Practices.EnterpriseLibrary.Logging]][]
7aa3ef4c 76177 6703576 System.Diagnostics.EventLog
0e8b40bc 361327 7391332 System.Object[]
12b701bc 342758 8226192 System.Collections.Generic.List`1[[System.Diagnostics.TraceListener, System]]
1281cfa8 342747 9596916 Microsoft.Practices.EnterpriseLibrary.Logging.LogSource
1281cb40 456996 12795888 Microsoft.Practices.EnterpriseLibrary.Logging.Instrumentation.LoggingInstrumentationProvider

There is a one line reference in the documentation that when working with Unity you should use the ExceptionManager rather then the ExceptionPolicy, but EntLib's ExceptionCallHandler doesn't do this.

I couldn't find any documentation around implementing the ExceptionManager but there was a basic example in the QuickStarts. When I created my own CallHandler using the ExceptionManager I ran into problems resolving the constructor parameters of ExceptionManager that should have been setup by the ExceptionHandlingBlockExtension.

While making the exceptionPolicy static and only calling the Factory on the first call "fixed" the memory usage I dont think the the ExceptionPolicy's members are thread safe so this is not realy a workable solution.

 Do you know of any examples of using the ExceptionManager from within a CallHandler or another method to stop the ExceptionsPolicy rooting so many objects in memory?


My exception handling config is as follows

     <add name="Exception Policy">
         <add type="System.Exception, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="NotifyRethrow" name="Exception">
             <add logCategory="Exception" eventId="0" severity="Error" title="Enterprise Library Exception Handling" formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" priority="0" useDefaultLogger="false" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="Logging Handler" />

 And here is extract of the unity configuration being used

<container name="ServiceInterface">
   <!-- Extentions to support the ExceptionManager -->
   <!--<add type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Unity.EnterpriseLibraryCoreExtension, Microsoft.Practices.EnterpriseLibrary.Common" />
         <add type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.Unity.ExceptionHandlingBlockExtension, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling" />-->
   <add type="Microsoft.Practices.Unity.InterceptionExtension.Interception, Microsoft.Practices.Unity.Interception" />
   <add name="interception" type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationElement, Microsoft.Practices.Unity.Interception.Configuration">
       <policy name="All Services Policy">
           <callHandler name="Exception Handling" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.ExceptionCallHandler, Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
                 <param name="exceptionPolicyName" parameterType="System.String">
                   <value value="Exception Policy" />
                 <param name="order" parameterType="System.Int32">
                   <value value="1" type="System.Int32" />
       <interceptor type="Microsoft.Practices.Unity.InterceptionExtension.InterfaceInterceptor, Microsoft.Practices.Unity.Interception">


Sep 7, 2011 at 9:38 AM


It seems this is an existing issue with 4.1 as I found a thread similar to your problem. Regarding with custom call handler, I don't have an idea how to create an instance of ExceptionManager (with 5.0, you can just call EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>). I believe you can still use the ExceptionPolicy since the issue has been fixed on this work item. Moving on, I believe this memory issue has been fixed on Entlib 5.0 as I noticed that piece of code is no longer there. I recommend you to migrate to 5.0 if there is no or less impact to your application.


Noel Angelo Bolasoc
Avanade Software
Avanade, Inc.


Sep 7, 2011 at 12:29 PM

Currently upgrading to EntLib 5 is not an option for us.

I had previously read the thread you linked to, but that is not the issue we are seeing and as mentioned in that thread and also the work item you linked to both were fixed in v4.1 so shouldn't be affecting me.

I've looked at the code change made in EntLib 5 for this Handler but they're still using the ExceptionPolicy rather then the ExceptionManager, but they are constructor injecting the ExceptionPolicy instead of using the factory.

 I will try doing this in a custom CallHandler and see what happens.

Sep 19, 2011 at 4:09 AM


Also, can you replicate the problem in a simple repro project? If you have this already can you kindly send it to us for us to further investigate. Thank you.

Gino Terrado
Global Technologies and Solutions
Avanade, Inc.
Contact Us