-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propogate ExecutionContext when run in IIS #31
Comments
Why not use |
httpContext will not be propagated across async/await. So we need to set |
What exactly do you mean by that?
The IIS pipeline isn't a single asynchronous call chain and I don't know if ASP.NET captures and restores the execution context when pipeline events execute. |
Sorry for mixing up the issues. I think there are two I mostly concerned of:
I know the limitation of |
By "context" you mean async local right?
I don't get that part (forgive me). If you set state in httpContext.Items, why wouldn't that flow to the controller action? Also it should be available in |
In this code condition So far the only solution I know if to register Action Filter (like I explained here). It will give the callback I need. However it looks like overkill to register both - middleware for time and other middlewares tracking and Action Filter for correlation inside the Controller.
|
Why not just always store the context in the httpContext? Don't use async locals when you're in System.Web... |
Because the httpcontext is null inside the |
But it does work without the .ContinueWith right? await client.GetStringAsync("http://bing.com");
if (System.Web.HttpContext.Current != null)
{
var ctxValue = System.Web.HttpContext.Current.Items["a"];
}
var alCtxValue = HomeController.ctx.Value; |
ContinueWith does not preserve the |
yes, I have Http Context before and after the await in your example. However it's not enough. For instance, when on FW 4.5 we collect http calls using Also quite often I need to correlate exception happened in those Yes, sorry I meant |
I've updated the title of the bug to accurately reflect the request. I don't think it's katana's job to flow the execution context across IIS events. |
Thank you! I do not know enough, but my understanding was that middleware and Controller executes in the same managed thread and Katana explicitly clear up context when in IIS. It would be great if it will not do it when possible |
It doesn't have anything to do with the same thread per se but the fact that they run in different IIS events is the problem. The execution context isn't preserved between these 2 events. You can see this by looking at the "call stack" during controller execution. You'll see the middleware pipeline isn't there. |
Just discussed it with @lmolkova. So re-setting the |
Yes that works if the handler completes synchronously. If it's async then it won't flow to the controller. |
@SergeyKanzhelev I assume you got unblocked, so closing this. But if that's not the case, let me know and I'll reactivate. |
Using something like HttpContext.Current is not a good idea at all. It does not work outside IIS, and inside IIS it has a lot of limitations. I've configured Owin, web API, OData, signalr, entity framework with Autofac, and I pass a per request instance of my own ILogger into all classes I need logging using constructor injection, so in my continueWith call I've a direct reference to my ILogger. Combining this with DRY concept will make a very powerful approach for logging which works anywhere |
Remember that things have changed too in .NET Core. my approach is working fine on .NET Core 2 too |
@davidfowl , can you please elaborate on this. Did you mean that |
Moving bug from the codeplex as it is still an issue for us with no easy solution.
If you develop OWIN middleware for monitoring you need to use
ThreadAsync
orCallContext
to keep the context across theasync/await
. And it is working fine. However if you try to use the same middleware when hosting your application in IIS - it doesn't propagate the context any longer.Even better if there will be a possibility to set the context from
HttModule
'sBegin
callback that will be preserved to the controller execution.The text was updated successfully, but these errors were encountered: