patterns & practices - Unity

Created Issue: IndexOutOfRangeException After ApplicationPool Recycle [11791]

RickF — Tue, 21 Feb 2012 21:44:00 GMT

It looks like the List within DependencyResolverTracker.AddResolverKey is used in a way which is possibly not be thread-safe.

This caused us many IndexOutOfRangeExceptions randomly after an application pool recycle. Simply recycling the application pool again resolved the issue.

Details of the stack are

Exception is: IndexOutOfRangeException - Index was outside the bounds of the array. 
-----------------------------------------------
 At the time of the exception, the container was:

 Resolving Fred.Services.Person.ViewListing,ServiceHost (mapped from Fred.Services.Person.IViewListing, ServiceHost)
 ----> System.IndexOutOfRangeException: Index was outside the bounds of the array.
 at System.Collections.Generic.List`1.Add(T item)
 at Microsoft.Practices.ObjectBuilder2.ConstructorSelectorPolicyBase`1.CreateSelectedConstructor(IBuilderContext context, IPolicyList resolverPolicyDestination, ConstructorInfo ctor) in e:\Builds\Unity\UnityTemp\Compile\Unity\Unity\Src\ObjectBuilder\Strategies\BuildPl...)." time="2012-02-16T21:14:59.0249474Z">

See this discussion for further info on it.
http://unity.codeplex.com/discussions/328841

Thanks
Rick

New Post: IndexOutOfRangeException After ApplicationPool Recycle

SFence — Tue, 21 Feb 2012 12:53:56 GMT

The issue seems to be with Unity itself, as resolution methods are supposed to be thread safe.

I can only recommend that you register an issue in the issue tracker.

SFence

Commented Issue: IBuilderContext.Locator from Unity 1.2 doesn't exist in Unity 2.0 [8028]

oligagne — Tue, 21 Feb 2012 02:12:08 GMT

Hello

is there a work around for this breaking change?

Thanks,
Costas
Comments: ** Comment from web user: oligagne **

and how you do this?!?

New Post: IndexOutOfRangeException After ApplicationPool Recycle

rickf — Mon, 20 Feb 2012 22:46:54 GMT

Hi SFence,

Agree with your conclusions. It does look like the List within DependencyResolverTracker.AddResolverKey could possibly not be thread-safe.

It is very possible that we have multiple threads simultaneously resolving these dependencies. Is this something we should be guarding against in our code when we're resolving the dependencies or is this an issue with Unity itself?

It appears that during the AppPool startup somehow this List got corrupted and thus ongoing resolution of only one type was causing us a problem in an isolated part of our website.

Thanks

Rick

New Post: Registration to child container

ctavares — Mon, 20 Feb 2012 22:18:37 GMT

Yeah, this is an unfortunate corner case due to the internals of the design.

Basically, all registrations except type mappings are keyed off concrete types, not interfaces. So when you do what you did in the first post, Unity will:

1) Look up type mapping: ITest -> Test

2) Look up factory for type Test

It doesn't matter that you've got a factory registered for ITest in the child container, because by the time you get to that stage in the creation pipeline, the container's no longer looking for ITest.

That's why doing RegisterType<ITest, ITest> works - it finds a type mapping ITest -> ITest, and then goes looking for a factory for ITest.

New Post: Registration to child container

RafalFurman — Mon, 20 Feb 2012 16:44:37 GMT

Thanks that is what I needed to know.

New Post: Registration to child container

weberse — Mon, 20 Feb 2012 15:01:08 GMT

OK, now I get your point. You don't know which Type your factory will create in the end. If you change the registration to

child.RegisterType<ITest, ITest>(new InjectionFactory(c => new Test2));

Identical source and destination types will also solve your problem. It has something to do with the way Unity handles type mappings and build keys.

New Post: Registration to child container

RafalFurman — Mon, 20 Feb 2012 14:42:53 GMT

I would. This is only sample code. I write integration layer with some old code that provides me with type factory that I'm supposed to use in certain situation. By understanding it I can determine the type that will be returned form it.

But what if I couldn't. Or if decision would be made in runtime base on some application state what then?

New Post: Registration to child container

weberse — Mon, 20 Feb 2012 14:27:50 GMT

You could also use the non-generic overload of RegisterType

child.RegisterType(typeof(ITest), typeof(Test2), new InjectionFactory(c => new Test2()));

But if you determine the implementation Type dynamically, why would you create it yourself via a factory and not let Unity decide how best to create an instance of your implementation?

New Post: Registration to child container

RafalFurman — Mon, 20 Feb 2012 14:23:50 GMT

Thanks, this solution works for me, but isn't that odd that this second type is required? What if I wanted dynamically determine implementation type to use?

New Post: Registration to child container

weberse — Mon, 20 Feb 2012 13:51:21 GMT

var container = new UnityContainer();
var child = container.CreateChildContainer();
container.RegisterType<ITest, Test>();
child.RegisterType<ITest, Test2>(new InjectionFactory(c => new Test2()));
var sut = child.Resolve<ITest>();
Assert.IsInstanceOfType(sut, typeof(Test2));



If you provide source and destination type for the registration it works fine.

New Post: Registration to child container

RafalFurman — Mon, 20 Feb 2012 13:03:02 GMT

Consider code:

var container = new UnityContainer();
container.RegisterType<ITest, Test>();
var childContainer = container.CreateChildContainer();
childContainer.RegisterType(typeof(ITest), new InjectionFactory((x) => new Test2()));
var result = childContainer.Resolve<ITest>();
Console.WriteLine(result.GetType().FullName);

I expected to get instance of Test2 from child container instead I got Test. Can you explain me why?

The other test I created works as I expected:

var container = new UnityContainer();
container.RegisterType<ITest, Test>();
var childContainer = container.CreateChildContainer();
childContainer.RegisterType<ITest, Test2>();
var result = childContainer.Resolve<ITest>();
Console.WriteLine(result.GetType().FullName);

New Post: IndexOutOfRangeException After ApplicationPool Recycle

SFence — Mon, 20 Feb 2012 11:16:09 GMT

Hi Rick,

Do you have multiple threads simultaneously resolving dependencies from the container ?

New Post: How to swallow Exception by IInterceptionBehavior?

berkaykurtarab — Mon, 20 Feb 2012 06:35:17 GMT

Try using

IMethodReturn result = getNext().Invoke(input, getNext);

instead of

IMethodReturn result = getNext()(input, getNext);

New Post: IndexOutOfRangeException After ApplicationPool Recycle

RickF — Sun, 19 Feb 2012 22:34:47 GMT

Hi All,

Last Friday morning we had a very unusual ocurance. We deployed a small change to our website, after which we performed an application pool recycle for it to pick up these changes. Immediately our ASP.Net 4.0 site had issues with one particular section (the rest of the site was performing perfectly). We were getting thousands of these exceptions in the logs.

Exception is: IndexOutOfRangeException - Index was outside the bounds of the array. 
-----------------------------------------------
 At the time of the exception, the container was:

 Resolving Fred.Services.Person.ViewListing,ServiceHost (mapped from Fred.Services.Person.IViewListing, ServiceHost)
 ----> System.IndexOutOfRangeException: Index was outside the bounds of the array.
 at System.Collections.Generic.List`1.Add(T item)
 at Microsoft.Practices.ObjectBuilder2.ConstructorSelectorPolicyBase`1.CreateSelectedConstructor(IBuilderContext context, IPolicyList resolverPolicyDestination, ConstructorInfo ctor) in e:\Builds\Unity\UnityTemp\Compile\Unity\Unity\Src\ObjectBuilder\Strategies\BuildPl...)." time="2012-02-16T21:14:59.0249474Z">

To resolve the issue all we did was recycle the application pool again (however it took us a about 30 minutes to realise this was happening).

What is strange is we have a farm of 9 web servers all which were recycled around the same time. We also recycle app pools nearly twice a day (for deployments and other changes) and we have never seen this problem before in the 18 months of using Unity.

We are using Microsoft.Practices.Unity version 2.0.414.0.

I've also noticed someone else having a very similar problem but with no resolution.

http://groups.google.com/group/webformsmvp/browse_thread/thread/d0bc697c702606aa?pli=1

Is there a bug in Unity that occurs randomly when handling application pool recycles or is there something else we need to know of?

Thanks

Rick

New Post: Planning for Unity vNext?

weberse — Mon, 13 Feb 2012 10:43:58 GMT

The last checkin for the contrib project was done in 02/2009. Before I would put any effort or code in that project I would like to know

How are contributions to that project handled? Can you checkin anything as soon as you are a developer on that project?
Can you change your code later as you see fit?
Is there some kind of release planning you need to follow?
Is there some kind of QA in place? E.g. code reviews?

And I agree with @rprimrose: Are there any plans that features from the contrib project will find their way into the Unity core?

New Post: Planning for Unity vNext?

rprimrose — Mon, 13 Feb 2012 03:46:56 GMT

Thanks for the thoughts about my IDisposable teardown extension.

I have previously thought about putting my extension in the contrib project. I'm reluctant to do this as it is already in my toolkit assembly. Granted this means that people need to add another assembly reference, but it means that the code exists in only one place. I would definitely put it in the contrib project if that was some kind of path towards getting it put into the Unity core itself, but am otherwise reluctant.

Thoughts?

New Post: ResolveTrampoline implementation

SFence — Sun, 12 Feb 2012 19:03:26 GMT

Hi,

Correct me if I'm wrong, but I'm under the impression that Func<T> deferred resolution is, by design, supposed to work as similarly as possible to traditional type resolution. However, the resolution of the deferred dependency in ResolveTrampoline<TItem>.Resolve (ObjectBuilder\Strategies\BuildPlan\Factory\DeferredResolveBuildPlanPolicy.cs) is done via a completely independent "external" call to the container, that drops any notion of the current build context. Therefore, a lot of functionalities are lost. For example, this test fixture will fail:

[TestMethod]
public void HonoursPerResolveLifetimeManagerWhenResolvingFunc()
{
    var container = new UnityContainer()
        .RegisterType<ILogger, MockLogger>(new PerResolveLifetimeManager());

    var resolver = container.Resolve<Func<ILogger>>();
    var result1 = resolver();
    var result2 = resolver();

    Assert.AreSame(result1, result2);
}

It is possible to get this test to pass, along with the 977 other tests, by modifying the ResolveTrampoline to accept the build context, and calling IBuilderContext.NewBuildUp rather than IUnityContainer.Resolve. Do you see any contraindication that I should be aware of ? I suspect there is a good reason why it has not been done by the developers, but I can't see it.

Thanks in advance

New Post: How to resolve constructor parameter?

miksu — Sat, 11 Feb 2012 17:02:04 GMT

Here's a blog post which shows how use the ParameterOverride (which perfectphase already described) and which also contains a custom resolver which doesn't require passing in the parameter names.

New Post: How to config interception in cfg file?

randylevy — Fri, 10 Feb 2012 04:13:24 GMT

You can configure your call handler using Policy Injection. A sample configuration based on your classes would be something like this:

  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
        
    <sectionExtension type="Microsoft.Practices.Unity.InterceptionExtension.Configuration.InterceptionConfigurationExtension, Microsoft.Practices.Unity.Interception.Configuration"/>
  
    <container>
      
      <extension type="Interception"/>

      <interception>

        <policy name="Policy">
          <matchingRule name="Match" type="UnityCallHandlerConfig.AnyMatchRules, UnityCallHandlerConfig" />
          <callHandler name="MyInterceptor" type="UnityCallHandlerConfig.MyInterceptor, UnityCallHandlerConfig"/>
        </policy>
        
      </interception>

      <register type="UnityCallHandlerConfig.IInterceptable, UnityCallHandlerConfig" mapTo="UnityCallHandlerConfig.BizClass, UnityCallHandlerConfig">
        <interceptor type="TransparentProxyInterceptor"/>
        <policyInjection />
      </register>
    
    </container>
 
  </unity>

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com