-
Notifications
You must be signed in to change notification settings - Fork 165
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
Adding ${aspnet-request-posted-body} gives exceptions and hangups #753
Comments
It would be very useful to know where threads are stuck/waiting, when it "hangsup" It would also be useful to have the NLog InternalLogger output at Debug-Level ( |
Maybe do this: var app = builder.Build();
app.Use(async (context, next) => {
context.Request.EnableBuffering();
await next();
}); See also: #556 Maybe need to update this for .NET5 + 6: https://github.com/NLog/NLog/wiki/AspNet-Request-posted-body-layout-renderer But would like to fix the "hangsup"-issue, so it fails nicely when something is wrong, instead of getting stuck. But need some input to know where to look. |
Those renderers are not essential for me so after figuring out that they cause the problem I simply stopped using them. So with debug internal log - when i clear this file just before this invoke there is no much in log file:
But when I didn't clear this file before invoking, there was something interesting from previous - successful invoke:
Pay attention to time, there is 2 seconds break which indicates when previous invoke finishes. Above one was wihthout adding:
After adding this I started the application and invoked exactly twice bellow curl: curl -k -X POST https://localhost:4433/withBody --data "{\"Id\": \"Abc\" }" --header "Content-Type:application/json" second attempt caused hangup, here you have full logs, including startup (with 2seconds break you can indicate when previous invoke finishes and new one starts):
|
Well I'm not expert user for NLog.Web-LayoutRenderers or ASP.NET Core. I mostly focus on NLog-core. Also doesn't have VS2022 installed, only VS2019 (so no net6 for me).
Interesting how many LogEvents from the ASP.NET.Core-engine that happens outside a valid HttpContext. But I guess that is all the logging happening a startup, before handling the first HttpRequest.
Looks like the only safe place to read Body-stream is when inside the middleware of the HttpRequest/HttpContext. But puzzled how this situation occurs when 2 threads are handling the same context. Guess if the async-streaming of the request-body is producing some logging output, then it will cause NLog to suddenly also start async-streaming of the same request-body. Guess NLog should only read until Body.Length and not stream to the end with StreamReader. Seems that ASP.NET Core applications first close all open streams, and then dispose the HttpContext, and just before disposing the HttpContext, then it produces a LogEvent with request-completed-timings. In this state, then only some features of the HttpContext is working (making parts of HttpContext "dangerous" to use). Funny part is when using |
@304NotModified Guess the correct thing is to remove One need to be in a safe place before trying to read Instead a wiki-page should be created for how to setup logging of request-body using standard-Logger inside ASP.NET Core middleware. Ex. placing a copy of the request-body as ScopeContext-Property, or put it into |
I don't use VS2022 as well (I use Rider), it's enough to install the latest dotnet sdk and But solution with removing those things is enough for me, for me those are not essential. The only reason I used them is that it was in getting started nlog wiki - https://github.com/NLog/NLog/wiki/Getting-started-with-ASP.NET-Core-6 - I thought: nice feature, but I'm fine to live without it :) I created the issue because I use NLog for about 7 years and after finding a bug wanted to give back at least this small effort to you guys :) I'm not blocked with my work (since I know what causes the problem and how to avoid it). |
Does the problem with "hangsup" appear with other aspnet-layoutrenderers, or only when used in combination with
Have now updated the tutorial to no longer mention
Also very happy about NLog, though it has received some strange warts over time. But I guess that happens for all software that have celebrated 10 years anniversary, but I really like the earned arsenal of unit-tests :) |
Maybe we should replace it with middleware indeed. |
Thanks to @bakgerman now NLog.Web.AspNetCore v5.1 re-introduces ${aspnet-request-posted-body} with help from middleware: app.UseMiddleware<NLog.Web.NLogRequestPostedBodyMiddleware>(); It is no longer necessary to explicit call |
Type: Bug
NLog version: 4.7.13
NLog.Web.AspNetCore version: 4.14.0
NLog.Extensions.Logging version: --
Platform: .Net 6
Current NLog config:
Csproj:
Program.cs:
Properties/launchSettings.json
Invoke.sh:
When using asp.net core renderers in layout (at least two of them, for what I have noticed), whole process hangsup (not deterministically, sometimes it works, sometimes not) when processing post request with body.
Scenario:
dotnet run
sh invoke.sh
(in separate bash session)sh invoke.sh
(in separate bash session)sh invoke.sh
(in separate bash session)CTRL+C
dotnet sessionIn my environment (Windows) it usually hangs on first attempt, rarely I need to repeat above steps twice or three times. But if I remove from layout two renderers and leave only one, for example only
${aspnet-request-posted-body}
then everything works fine every time I try.The text was updated successfully, but these errors were encountered: