Allow manual specification of filewatcher behavior#29
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
As seen with PR #28, there are some performance problems with the polling filewatcher.
It seems, that in newer macos versions, we have fsnotify events available as well. However, to avoid a braking change, and until we can verify what docker desktop version and which settings enable this, we are for now introducing an environment variable so users can manually override the automatic decision.
This will also be useful once we change the default behavior (e.g. with #28), to give users an option to go back to the current behavior.
Changes
LOCALSTACK_FILE_WATCHER_STRATEGYconfig, with to possible options:eventandpolling. Event uses file system events, polling our poller like currently on Docker Desktop. Specifying this option will override the default handling, if it is empty, the current behavior is preserved. If set to something other thaneventorpolling, the init binary will crash to indicate an incorrect configuration.