-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support asynchronous CommandStore message processing #27
base: trunk
Are you sure you want to change the base?
Conversation
…can be implemented by e.g. scanning sstables
6dd1a7d
to
d2c1674
Compare
ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rename zSlowSearcherand
SlowSearchFunctionto something like
IncrementalSearcher` or whatever seems more descriptive and add a comment that the motivation is to allow implementations to process results without caching all of them or blocking for a long time or to avoid bringing them into the cache?
Otherwise yeah I am basically +1
Oh, somehow I missed you +1'd this. I'll rebase this perhaps onto bootstrap. |
6a9482b
to
4a8566a
Compare
c3a1d8f
to
efc6a38
Compare
289d5ea
to
064735b
Compare
2edc7fb
to
a271897
Compare
50d6ef9
to
bd0761c
Compare
While messages are submitted to a CommandStore asynchronously, the processing of a message is then expected to be synchronous. However, it would be beneficial particularly for large range transactions, but also for recovery, to be able to defer some work that might involve IO to after the command store processing completes, e.g. for calculating dependencies.