There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?
UnityContainer Pipeline Behavior when using Interception
Our recent application deployed to production is facing performance issue and users are revoked access because of the same. It’s observed that application response time is degrading quite often and sometime IIS application is crashing as well. Microsoft
has provided an analysis to indicate that our application Service code has looping issue while using unity container framework.
We are facing issue related to Enterprise Library Unity Container. We maintain an application cache on our application server side for some entities (5 business entities). We have used unity container interception feature to intercept calls in our façade layer
(data provider layer in application server) to decide whether the required entity exists in the cache or not. It has been observed in MS dump utility trace and in our application logs, that a huge number of calls are made to our CacheHandler that is configured
with Unity framework for cached entities. This is causing stack overflow issue on the server and memory usage is growing as well very rapidly. This is resulting our IIS app(application service layer) to respond very slow or sometime even crashing the IIS app
After a code analysis and debugging it has been found out that we use httpmodule which is using a unity container instance. Httpmodule is used to handle “PostMapRquest” http pipeline event. In this event handler we create a new extension to the unity container
each time a call made to the server. In the new extension we also do register our provider instances for interception along with the interceptor. On the cachehandler whenever we check for the entity we call the following method for going ahead with the next
// Call the original method
result = getNext()(input, getNext);
As per our understanding the call above triggers the Unity pipeline and invokes each extension and behaviors underneath. This is causing more calls to our Cachehandler than expected. As the HttpModule lives as long as the IIS application lives , unity container
is growing big whenever each call is made.
We will not keep the instance of UnityContainer once the service call is executed. For each call we will instantiate a new unity container and just before the Post Map request event handler ends we will remove all extensions from the unity container and dispose
// Clear all the extensions when application context is created.
We will also modify the code to restrict registering only one type of provider to UnityContainer for one time only. This will reduce the no of providers underneath and will reduce the cachehandler call within a single flow. We will follow Unity Config file
to do the registration to avoid multiple registration. Please let us know your recommendation and let us also know if we are correct on our analysis.