OWIN/ WebApi2 nested lifetimescope exception

[tillig]

From @tynor88 on September 12, 2016 9:11

Hi

Having followed the WebApi2 + OWIN integration documentation, I am facing an exception I cannot figure out how to solve.

Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it has already been disposed.

Stacktrace: [ObjectDisposedException: Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it has already been disposed.] Autofac.Core.Lifetime.LifetimeScope.CheckNotDisposed() +67 Autofac.Core.Lifetime.LifetimeScope.BeginLifetimeScope(Object tag, Action1 configurationAction) +30 Owin.<<RegisterAutofacLifetimeScopeInjector>b__0>d.MoveNext() +200 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +13908768 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +61 Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.<RunApp>d__5.MoveNext() +203 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +13908768 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +61 Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.<DoFinalWork>d__2.MoveNext() +193 Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.StageAsyncResult.End(IAsyncResult ar) +96 System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +363 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +137

I am not creating any new lifetime scopes myself. I've created a sample project which is similar to my current setup.

It's difficult for me to debug, as this exception only happends when the site is deployed to a Virtual Machine (Windows Server 2012) running IIS 8.5. The exception occurs randomly whenever I hit either the WebApi2 endpoint or the OwinMiddleware HelloWorld endpoint. I even tried the Remote Debugging tools, and whenever I remote debug, the OWIN / WebApi2 endpoints work just fine.

It seems like the issue is around line 35 of the code in Startup.cs class:

        public void Configuration(IAppBuilder app)
        {
            var config = new HttpConfiguration();
            IContainer container = Bootstrapper.Bootstrap;

            ILogger logger = container.Resolve<ILogger>();

            try
            {
                config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
                app.UseAutofacMiddleware(container);

                app.UseAutofacWebApi(config);
                app.UseWebApi(config);

                config.MapHttpAttributeRoutes();

                //This line seems to give me some problems - If i don't call Foo() here, everything is working normally.
                //Foo is just manipulating a configuration file - services injected into it are just Singleton's.
                container.Resolve<IService>().Foo();
            }
            catch (Exception ex)
            {
                logger.Error(ex, "Unhandled exception occured");
                throw;
            }
        }
`

_Copied from original issue: autofac/Autofac#795_

[tillig]

I grabbed your sample project and was able to build and run it with no issues - got to the /HelloWorldWebApi/ GET route that was in the app with no unhandled exceptions. Perhaps one of the omitted middlewares is what's causing the exception? Or possibly you have something installed in your GAC that is getting used instead of the stuff from NuGet?

You may want to try reproducing this on a different machine.

Regardless, I can't reproduce it. Sorry. I'm going to close it for now. If you come up with a repro that I can get to fail on my machine, I'd be happy to reopen.

[normanhh3]

@tillig did you find a resolution for this issue?

[tillig]

Per last update, I couldn't reproduce the issue, so... No.

[huysentruitw]

Seems like I'm having the same problem https://github.com/graphql-dotnet/conventions/issues/49, so please don't give up on this one.

[tillig]

If I can't repro it, I can't troubleshoot it. Without additional info there's nothing I can do. It's not "given up," it's "help me help you." Need a repro or need someone with an app where this is happening to do root cause analysis. Until then, the issue is closed because there is literally no more action that can be taken on our end.

[huysentruitw]

I understand. Tried to reproduce it myself with only WebApi and Autofac, but I can't. So it might have something to do with the GraphQL conventions library I'm using, maybe some async behavior that is no longer awaited on.

[normanhh3]

I saw this again today and I am now believing that the issue happens when deploying code without doing a clean transfer of the load off of the server before making the changes. In my case I believe that a proper startup/shutdown process for the IIS site as well as the app pool involved should alleviate this issue.

Not sure what to do to recreate this scenario in a controlled environment though.

Maybe an automated load test?

On Jun 28, 2017 10:25 AM, "huysentruitw" notifications@github.com wrote:

I understand. Tried to reproduce it myself with only WebApi and Autofac, but I can't. So it might have something to do with the GraphQL conventions library I'm using, maybe some async behavior that is no longer awaited on.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/autofac/Autofac.WebApi/issues/18#issuecomment-311674047, or mute the thread https://github.com/notifications/unsubscribe-auth/ABj7xMD-t--PB4vKCZOyoV4qJvPvpc5gks5sImDlgaJpZM4J6yM4 .

[huysentruitw]

@tillig After a full day of debugging, adding middleware spitting out debug messages, I found that the root cause of the issue was totally unrelated to Autofac. I can also say that Autofac and Autofac.WebApi is stable AF 👍

If one gets into this issue, then you're probably:

• run code in a different thread because of bad async usage (i.e. not waiting for the result)
• run code in a different thread and not waiting for it (Task.Run(() => {}) anyone?)
• sharing an instance of the request scope between different API calls

[tillig]

Really glad you figured it out. Thanks for taking the time to track it down!