-
Notifications
You must be signed in to change notification settings - Fork 510
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
Search stability improvements #1033
Conversation
…r improvments for mutex contention and Results channel panics Signed-off-by: Martin Disibio <mdisibio@gmail.com>
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.
lgtm. probably another couple of eyes would be good
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.
Really nice batch of changes, just one comment on trying to understand the deadlock state better.
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 add a bunch of bugfixes to the Changelog :)
Looks good to me, but we are getting a test timeout in integration tests.
|
The test that timed out is |
If the |
Unable to reproduce the flakey tests locally, and consensus is they are likely not caused by these changes. Merging. |
What this PR does:
This PR fixes several rough spots:
instance.writeTraceToHeadBlock
, by takingi.blocksMtx
until all search routines are started ininstance.Search
channel already closed
andsend on closed channel
insearch.Results
by redoing the cleanup and usingsync.WaitGroup
t.TempDir
, behavior discussed here: golang/go/issues/43547StreamingSearchBlock.FlushBuffer
with a mutexWhich issue(s) this PR fixes:
Fixes n/a
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]