#69: Fix inotify watch problem + update to .NET 7 #70
Conversation
nbokmans
changed the title
| @@ -178,7 +178,7 @@ IEnumerable<string> GetResourceFiles(string culture) | |||
| if (File.Exists(filePath)) | |||
| { | |||
| var builder = new ConfigurationBuilder() | |||
| .AddJsonFile(filePath, optional: true, reloadOnChange: true); | |||
| .AddJsonFile(filePath, optional: true, reloadOnChange: false); | |||
There was a problem hiding this comment.
This change is dangerous, so whever your change the JSON file it will not reload the changes
There was a problem hiding this comment.
Yes, that is precisely what I am trying to fix. The reloadOnChange: true flag seems to be bugged in ASP.NET on Linux, in which it does not release the inotify instances for the file system watcher. On production webservers where a limit is configured (very common), this will eventually make it so your app stops responding. Changing it to reloadOnChange: false makes it so no inotify instances are created for the JSON resource file you are trying to read. Also I figured that generally speaking, in staging/production environments, the json resource files will not change during runtime. I've linked some related reading material in the issue description here: #69 and dotnet/runtime#62869 and https://www.travisgosselin.com/configured-user-limit-inotify-instances/
|
Just close and reopen to trigger the build again |
|
Thanks for your contribution, we might need to release |
|
But thus us not a fix - it is just a workaround... What if we need to have reloadOnChange = true? This solves nothing |
|
Waiting for a proper fix |
|
@suchoss feel free to come up with a better solution! I think I've argued clearly why You can always revert back to older version v2 where |
|
Fair enough, I understand that we need ASP.NET core team fixing this issue. |
|
Exactly |
This PR attempts to solve #69