Strange Exception in conjunction with Castle Windsor

84 views
Skip to first unread message

Richard Lennox

unread,
Sep 18, 2010, 10:20:14 AM9/18/10
to OpenRasta
Hi there,

We are seeing a strange issue within OpenRasta and in conjunction with
Castle Windsor. Does anyone have any ideas that might help?

See below for exception samples.

(null)2010-09-18 14:03:56 ERROR - An error has occurred and the
processing of the request has stopped.

Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the
array.
at System.Collections.Generic.List`1.Add(T item)
at Castle.Core.GraphNode.AddDependent(GraphNode node)
at
Castle.MicroKernel.Handlers.AbstractHandler.AddGraphDependency(ComponentModel
model)
at
Castle.MicroKernel.Handlers.AbstractHandler.AddDependency(DependencyModel
dependency)
at
Castle.MicroKernel.Handlers.AbstractHandler.EnsureDependenciesCanBeSatisfied()
at Castle.MicroKernel.Handlers.AbstractHandler.Init(IKernel kernel)
at
Castle.MicroKernel.Handlers.DefaultHandlerFactory.Create(ComponentModel
model)
at Castle.MicroKernel.DefaultKernel.AddComponent(String key, Type
serviceType, Type classType, LifestyleType lifestyle, Boolean
overwriteLifestyle)
at Castle.Windsor.WindsorContainer.AddComponentLifeStyle(String
key, Type serviceType, Type classType, LifestyleType lifestyle)
at
OpenRasta.DI.Windsor.WindsorDependencyResolver.AddDependencyCore(Type
dependent, Type concrete, DependencyLifetime lifetime)
at
OpenRasta.DI.Windsor.WindsorDependencyResolver.AddDependencyCore(Type
handlerType, DependencyLifetime lifetime)
at
OpenRasta.DI.DependencyResolverExtensions.Resolve(IDependencyResolver
resolver, Type type, UnregisteredAction unregisteredBehavior)
at OpenRasta.TypeSystem.TypeExtensions.CreateInstance(IType type,
IDependencyResolver resolver)
at
OpenRasta.OperationModel.MethodBased.MethodBasedOperation.Invoke()
at
OpenRasta.OperationModel.Interceptors.OperationWithInterceptors.<Invoke>b__0()
at
OpenRasta.OperationModel.Interceptors.OperationWithInterceptors.Invoke()
at OpenRasta.OperationModel.OperationExecutor.Execute(IEnumerable`1
operations)
at
OpenRasta.Pipeline.Contributors.OperationInvokerContributor.ExecuteOperations(ICommunicationContext
context)
at
OpenRasta.Pipeline.PipelineRunner.ExecuteContributor(ICommunicationContext
context, ContributorCall call)
(null)2010-09-18 14:03:57 ERROR - An error has occurred and the
processing of the request has stopped.

Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the
array.
at System.Collections.Generic.List`1.Add(T item)
at Castle.Core.GraphNode.AddDependent(GraphNode node)
at
Castle.MicroKernel.Handlers.AbstractHandler.AddGraphDependency(ComponentModel
model)
at
Castle.MicroKernel.Handlers.AbstractHandler.AddDependency(DependencyModel
dependency)
at
Castle.MicroKernel.Handlers.AbstractHandler.EnsureDependenciesCanBeSatisfied()
at Castle.MicroKernel.Handlers.AbstractHandler.Init(IKernel kernel)
at
Castle.MicroKernel.Handlers.DefaultHandlerFactory.Create(ComponentModel
model)
at Castle.MicroKernel.DefaultKernel.AddComponent(String key, Type
serviceType, Type classType, LifestyleType lifestyle, Boolean
overwriteLifestyle)
at Castle.Windsor.WindsorContainer.AddComponentLifeStyle(String
key, Type serviceType, Type classType, LifestyleType lifestyle)
at
OpenRasta.DI.Windsor.WindsorDependencyResolver.AddDependencyCore(Type
dependent, Type concrete, DependencyLifetime lifetime)
at
OpenRasta.DI.Windsor.WindsorDependencyResolver.AddDependencyCore(Type
handlerType, DependencyLifetime lifetime)
at
OpenRasta.DI.DependencyResolverExtensions.Resolve(IDependencyResolver
resolver, Type type, UnregisteredAction unregisteredBehavior)
at OpenRasta.TypeSystem.TypeExtensions.CreateInstance(IType type,
IDependencyResolver resolver)
at
OpenRasta.OperationModel.MethodBased.MethodBasedOperation.Invoke()
at
OpenRasta.OperationModel.Interceptors.OperationWithInterceptors.<Invoke>b__0()
at
OpenRasta.OperationModel.Interceptors.OperationWithInterceptors.Invoke()
at OpenRasta.OperationModel.OperationExecutor.Execute(IEnumerable`1
operations)
at
OpenRasta.Pipeline.Contributors.OperationInvokerContributor.ExecuteOperations(ICommunicationContext
context)
at
OpenRasta.Pipeline.PipelineRunner.ExecuteContributor(ICommunicationContext
context, ContributorCall call)

Thanks,
Richard

SimonT

unread,
Sep 20, 2010, 6:45:14 AM9/20/10
to OpenRasta
To add a bit more context, this problem occurs fairly infrequently in
production (though it's pretty serious when it happens...), suggesting
a concurrency issue (the strange List<>.Add error message also seems
to suggest a Threading issue). Looking at the OR source code, it looks
like the DependencyResolverExtensions method

public static object Resolve(this IDependencyResolver
resolver, Type type, UnregisteredAction unregisteredBehavior)
{
if (unregisteredBehavior ==
UnregisteredAction.AddAsTransient && !resolver.HasDependency(type))
resolver.AddDependency(type,
DependencyLifetime.Transient);
return resolver.Resolve(type);
}

registers the handler with the resolver on the first request for it.
We suspect that concurrent threads performing the same action is the
trigger for the issue. We've seem similar issues with Castle in the
past and have wrapped all existing application IoC registration in a
lock statement.

Our proposed short-term fix is to explictly register our handlers at
startup (inside lock statement). Will let you know how that goes. I'd
suggest that some sort of synchronization within the
WindorDependencyResolver would the the long-term solution?

Sebastien Lambla

unread,
Sep 23, 2010, 7:47:10 PM9/23/10
to open...@googlegroups.com
your dependency resolver should be created in a static, and the configuration code should have a lock around it (as far as I remember) to account for this scenario.

If you don't register your own handlers, there may indeed be a race condition if two requests come in at the same time for the same request. We should probably ensure the registration in the container is done on startup rather than upon first request.

If you could fill-in a bug request on youtrack.codebetter.com in the openrasta project, or send a pull request, we can add that to the 2.0 branch.
________________________________________
From: open...@googlegroups.com [open...@googlegroups.com] on behalf of SimonT [simonth...@hotmail.com]
Sent: 20 September 2010 11:45
To: OpenRasta
Subject: [openrasta] Re: Strange Exception in conjunction with Castle Windsor

Matt

unread,
Nov 12, 2010, 7:56:26 AM11/12/10
to OpenRasta
Hi Seb,

Has this issue been fixed? We have also encountered the exception the
original poster detailed in our production systems.

For the time being I'm going to manually register our handlers and see
if that clears up the problem.

Thanks,
Matt

On Sep 23, 11:47 pm, Sebastien Lambla <s...@serialseb.com> wrote:
> your dependency resolver should be created in a static, and the configuration code should have a lock around it (as far as I remember) to account for this scenario.
>
> If you don't register your own handlers, there may indeed be a race condition if two requests come in at the same time for the same request. We should probably ensure the registration in the container is done on startup rather than upon first request.
>
> If you could fill-in a bug request on youtrack.codebetter.com in the openrasta project, or send a pull request, we can add that to the 2.0 branch.
> ________________________________________
> From: open...@googlegroups.com [open...@googlegroups.com] on behalf of SimonT [simonthorog...@hotmail.com]

SimonT

unread,
Nov 13, 2010, 10:35:04 AM11/13/10
to OpenRasta
Hi - I can confirm that manually registering the handlers is an
effective workaround.
Reply all
Reply to author
Forward
0 new messages