DefaultDependencyResolver concurreny issue? ( "System.IndexOutOfRangeException: Index was outside the bounds of the array" )

[Aleksander Bethke]

Hey there,

we are experiencing some weird and completely random concurrency (seems so) issues with Castle Windsor (3.3.0).

We have ASP.NET MVC Application.

Container is bootstrapped in App Start and every registration happens there.

Looks like during app start/pool recycle randomly we got a lot of those errors and app wont respond unit next app pool recycle.

We have Custom Controller factory and Dependency Resolver based on Windsor container (nothing particular - examples and from Castle docs).

We use Collection Sub Resolver.

Exception below.

Any help/tips would be really appreciated.

If you need more details I will be more than happy to provide more info.

Thanks

System.IndexOutOfRangeException: Index was outside the bounds of the array.

   at System.Collections.Generic.List`1.Enumerator.MoveNext()

   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)

   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.CanResolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)

   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.ObtainPropertyValue(CreationContext context, PropertySet property, IDependencyResolver resolver)

   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.SetUpProperties(Object instance, CreationContext context)

   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)

   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)

   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)

   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)

   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)

   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)

   at Castle.MicroKernel.DefaultKernel.ResolveComponent(IHandler handler, Type service, IDictionary additionalArguments, IReleasePolicy policy)

   at Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve(Type service, IDictionary arguments, IReleasePolicy policy)

   at yTos.Core.MVC.Controllers.CastleWindsorControllerFactory.GetControllerInstance(RequestContext requestContext, Type controllerType)

   at System.Web.Mvc.DefaultControllerFactory.CreateController(RequestContext requestContext, String controllerName)

   at System.Web.Mvc.MvcHandler.ProcessRequestInit(HttpContextBase httpContext, IController& controller, IControllerFactory& factory)

   at System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object state)

   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

[Krzysztof Koźmic]

That stack trace looks like it's coming from https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor/MicroKernel/Resolvers/DefaultDependencyResolver.cs#L240

That would point to the CollectionResolver being added at a late point in the process, after the container has been fully constructed and began being used.

This however, obviously contradicts the very behaviour of App_Start which is thread safe and guaranteed to be only called once.

Could there be some other stuff happening somewhere else in the code that would affect the container?

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

sent from my phone
Krzysztof

[Aleksander Bethke]

Krzysztof, thank you for the response.

That is exactly what we've came with - Container modified once it has been bootstrapped.

Lately we've added Collection sub resolver and seems that errors began to show in that timeline.

We add it in the MvcApplication protected constructor like this:

Ctor:

protected MvcApplication()

{

     bootstrapper = new Bootstrapper(Container);

}

container.Kernel.Resolver.AddSubResolver(new CollectionResolver(container.Kernel));

Container is accessed in this way:

private static readonly object SyncRoot = new object();

        private static volatile IWindsorContainer container;

        private readonly Bootstrapper bootstrapper;

        protected MvcApplication()

        {

            bootstrapper = new Bootstrapper(Container);

        }

        private static IWindsorContainer Container

        {

            get

            {

                if (container != null)

                    return container;

                lock (SyncRoot)

                {

                    if (container != null)

                        return container;

                    container = new WindsorContainer().Install(FromAssembly.InThisApplication());

                }

                return container;

            }

        }

I may move this code inside Application_Start method.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

[Aleksander Bethke]

Hey all.

I think I've found the problem.

Krzysztof was right! We were adding Collection SubResolver in HttpApplication constructor that is called at least five times during application start/pool restart (have no idea why).

Moving all the bootstrap code into App_Start seems working.

Thanks!

On Wednesday, November 23, 2016 at 12:27:29 AM UTC+1, Krzysztof Koźmic wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

[Krzysztof Koźmic]

Cool. Glad you found the root cause :)

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

sent from my phone
Krzysztof

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.