Allow Tesla.Middleware.Fuse options to set the ask mode #493
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Under high load, forcing all calls to `:fuse.ask/2` to be synchronous (sent through the `fuse_server` process) can result in a deep mailbox and timeouts inside the middleware (hitting the default call timeout of 5s). This commit adds a `mode` option to the middleware that lets the user select `:async_dirty` so that the `fuse_server` process can be bypassed. In the documentation, I tried to be explicit that choosing `:async_dirty` might result in drift, meaning that a given process might read the fuse state from `ets` and it would not account for melts or resets that are in the mailbox of the `fuse_server` process. Because of potential side-effect/timing issues, it wasn't clear how to test this change. Any guidance there is appreciated!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Under high load, forcing all calls to
:fuse.ask/2to be synchronous (sentthrough the
fuse_serverprocess) can result in a deep mailbox and timeoutsinside the middleware (hitting the default call timeout of 5s). This commit adds
a
modeoption to the middleware that lets the user select:async_dirtysothat the
fuse_serverprocess can be bypassed.In the documentation, I tried to be explicit that choosing
:async_dirtymightresult in drift, meaning that a given process might read the fuse state from
etsand it would not account for melts or resets that are in the mailbox ofthe
fuse_serverprocess.Because of potential side-effect/timing issues, it wasn't clear how to test this
change. Any guidance there is appreciated!