Please check the type of change your PR introduces:
[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):
What is the current behavior?
When starting HttPlaceholder in a specific directory with a lot of (sub) folders, HttPlaceholder will scan all these folders and will place a lot of (Inotify) file watches to watch these files. This is very inefficient and completely unnecessary.
Checked with inotify-info when starting HttPlaceholder in my home directory on Ubuntu
What is the new behavior?
I found out this behavior is because we use the default web host builder for .NET MVC, which scans the appsettings.{env}.json and appsettings.json files by default. I don't know why so many watches are created, but by removing the scanning of appsettings.*.json files, it seems the problem went away. This is OK, because HttPlaceholder does not use the appsettings files at all.
Pull request type
Please check the type of change your PR introduces:
What is the current behavior?
When starting HttPlaceholder in a specific directory with a lot of (sub) folders, HttPlaceholder will scan all these folders and will place a lot of (Inotify) file watches to watch these files. This is very inefficient and completely unnecessary.
What is the new behavior?
I found out this behavior is because we use the default web host builder for .NET MVC, which scans the appsettings.{env}.json and appsettings.json files by default. I don't know why so many watches are created, but by removing the scanning of appsettings.*.json files, it seems the problem went away. This is OK, because HttPlaceholder does not use the appsettings files at all.
StackOverflow post: https://stackoverflow.com/questions/43469400/asp-net-core-the-configured-user-limit-128-on-the-number-of-inotify-instance
Does this introduce a breaking change?
Other information