-
Notifications
You must be signed in to change notification settings - Fork 51
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
test: Ensure that all databases are always closed on exit #1187
Conversation
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!
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
Codecov Report
@@ Coverage Diff @@
## develop #1187 +/- ##
===========================================
+ Coverage 68.76% 68.79% +0.02%
===========================================
Files 180 180
Lines 17046 17046
===========================================
+ Hits 11722 11727 +5
+ Misses 4372 4368 -4
+ Partials 952 951 -1 |
4d6ff7a
to
4af5447
Compare
This is really important for file based datastores, and failure to close even a couple will have a highly significant performance impact due to a long-term defra bug, where if the directory hosting defra is deleted whilst a database instance is active the instance will hang/infinate-loop chewing up a huge amount of resources. As the file based directories are deleted by `go test` at the end of each test, this magnifies the effect of any lingering instances. In the case of this issue I believe only a very small number of databases were leaked, yet it nearly doubled the execution time of the change detector (the only potential leaks I found were a couple of panics, and a couple of subscription tests, it could be that as few as 3-4 leaked databases were responsible for the loss of performance).
Sorry about the holdup, I moved the defer function from an inline declaration to a proper function shortly before opening the PR and my local runtimes have shot up again. Still trying to figure out why |
Branch without the breaking commit is now taking 15min locally... I'm just going to merge this and see if it sorts it. Is a good enough change to have anyway |
This is really important for file based datastores, and failure to close even a couple will have a highly significant performance impact due to a long-term defra bug, where if the directory hosting defra is deleted whilst a database instance is active the instance will hang/infinate-loop chewing up a huge amount of resources. As the file based directories are deleted by `go test` at the end of each test, this magnifies the effect of any lingering instances. In the case of this issue I believe only a very small number of databases were leaked, yet it nearly doubled the execution time of the change detector (the only potential leaks I found were a couple of panics, and a couple of subscription tests, it could be that as few as 3-4 leaked databases were responsible for the loss of performance).
…ork#1187) This is really important for file based datastores, and failure to close even a couple will have a highly significant performance impact due to a long-term defra bug, where if the directory hosting defra is deleted whilst a database instance is active the instance will hang/infinate-loop chewing up a huge amount of resources. As the file based directories are deleted by `go test` at the end of each test, this magnifies the effect of any lingering instances. In the case of this issue I believe only a very small number of databases were leaked, yet it nearly doubled the execution time of the change detector (the only potential leaks I found were a couple of panics, and a couple of subscription tests, it could be that as few as 3-4 leaked databases were responsible for the loss of performance).
Relevant issue(s)
Resolves #1186
Description
Ensures that all databases are always closed on exit.
This is really important for file based datastores, and failure to close even a couple will have a highly significant performance impact due to a long-term defra bug, where if the directory hosting defra is deleted whilst a database instance is active the instance will hang/infinite-loop chewing up a huge amount of resources. As the file based directories are deleted by
go test
at the end of each test, this magnifies the effect of any lingering instances. In the case of this issue I believe only a very small number of databases were leaked, yet it nearly doubled the execution time of the change detector (the only potential leaks I found were a couple of panics, and a couple of subscription tests, it could be that as few as 3-4 leaked databases were responsible for the loss of performance).Tested by executing the change detector by targeting this branch. The change detector will likely be slow in this PR and the problem will only be resolved upon merge to develop (as the issue is most visible in change detector startup).