-
Notifications
You must be signed in to change notification settings - Fork 22
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
KeepOpen and KeepOpenAndAutoFlush are not working #30
Comments
This sounds like you have two competing file logger provider instances in your application. A situation like the one that was discussed here. Misconfiguration of DI can lead to such issues. If this is not the case for you, then please send me some more details about your setup: OS type, OS version, .NET version, logger package version, etc. It would be the best if you could send me an MRE (minimial, reproducible example), that is, a simplified, working version of your application that's able to produce the issue. |
One more thing that came to my mind in the meantime: have you tried the |
Thanks for the prompt reply @adams85 Let me try the above. When I said "no logs" in the issue, I see the log file created but its empty. Just wanted to add that information here. Let me get back with results. |
Hi @adams85 Regarding your request for MRE, sorry to say it is not possible since your library is integrated to one of our corporate libraries and I am in turn using that corporate library to one of the console apps. But I can say the corporate library team has followed your documentation Here are my observations so far
"File": {
System.Diagnostics.Debug.WriteLine("# of file logger providers in root scope: " + app.ApplicationServices.GetRequiredService<IEnumerable>().OfType().Count());
I will get back with rest of the results meanwhile. |
When I used your code and executed the executable after release build
I get the error
I don't get the error when running connected to Visual Studio 2022. |
This points in the direction of two competing file queues, caused by either DI or logger misconfiguration. Let's check DI configuration first. Set FileAccessMode to OpenTemporarily, add the piece of diagnostic code below and run your app until you lose some log entries. var serial = 0;
var logProcessorNumbers = new ConcurrentDictionary<object, int>();
FileLoggerContext.Default.DiagnosticEvent += e =>
{
var logProcessorNumber = logProcessorNumbers.GetOrAdd(e.Source, _ => Interlocked.Increment(ref serial));
Console.WriteLine($"[#{logProcessorNumber}] {e}");
}; If your DI configuration is ok, you should not see any diagnostic message that starts with |
I ran with the below setting by publishing the app. I found that there was no loss of logs to my surprise.
I had the below type of log two times when I ran the process for few mins. Both times the serial number was
|
I ran the published app from command prompt by using the below setting
I see If I run from Visual Studio in Release mode I see only [#1] and there are no logs lost. Questions summary
Please advice |
This clearly shows that there is some problem with the DI configuration in your application. Somehow you end up with two instances of the file logger provider in your DI container while there should be only one. I advise revising the DI setup logic in your application. Check for multiple Temporarily replace the [ProviderAlias(Alias)]
public class MyFileLoggerProvider : FileLoggerProvider
{
public MyFileLoggerProvider(FileLoggerContext context, IOptionsMonitor<FileLoggerOptions> options, string optionsName)
: base(context, options, optionsName) {
} // set a breakpoint here
} Then run your application with a debugger attached and examine the callstack when the breakpoint is hit.
Without having more details on your application, I can't tell. Maybe it runs in different environments (e.g. Development vs. Production) in the two case and there are differences in the configuration between those environments.
I answered this at the beginning of my comment.
If your application is configured correctly, nothing should happen, i.e. it should work as expected. One thing to pay attention to: services may run under a restricted user account. You need to make sure that account has write permission to the folder where the logs are written.
That logger configuration looks good. However, I'd rather go with |
I used the above setting in published apps in VMs. It seems to work fine. So closing this issue. I will reopen if required. |
When I use the logger with Open Temporarily, is working fine. The issue I am facing in that is when I write lot of logs parallely I loose some logs.
Hence I just changed FileAccessMode to KeepOpen or KeepOpenAndAutoFlush. I didn't change anything else in my app.
I ran my console app for quite a while that writes a lot of logs. When I use KeepOpenAndAutoFlush, I see only the first log. When I tried with KeepOpen I see no logs. I also tried stopping the console app gracefully and waited for a while to see if logs get written. But no luck.
What am I missing?
The text was updated successfully, but these errors were encountered: