-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
[FAB-11334] Adds a function to purge a ledger's transient storage #2769
[FAB-11334] Adds a function to purge a ledger's transient storage #2769
Conversation
db72f29
to
daca3db
Compare
daca3db
to
666846e
Compare
// Determine if the lock is currently held open. | ||
func (f *FileLock) IsLocked() bool { | ||
return f.db != nil | ||
} | ||
|
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.
I won't over-emphasize this but just to take a note - as the introduction of this function now assumes (at this level of code) that this struct can be used by a more than one go routines, access to field f.db
should be protected. Else, a caller can get a wrong result from this function.
However, we are using this struct in a very limited way and don't foresee any plan to use this function in a test with concurrent go-routines, I am fine leaving it as is; but appreciate if you want to fix this for cleanliness at this level of the code.
b475cb8
to
09d21a2
Compare
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 now. A few final clean up comments.
This introduces a transientstore.Delete(ledgerID) routine to assist with the bookkeeping while unjoining a peer from a channel. Before removing the transient storage, the store is marked as UNDER_DELETION in a system leveldb, providing an opportunity to recover from a failed deletion at the next peer initialization. Signed-off-by: Josh Kneubuhl <jkneubuh@us.ibm.com>
09d21a2
to
c1dc94e
Compare
OK. I think this one is a wrap. I agree we should look to find a wider grain / common lock to handle "peer is running" concurrently with CLI activities requiring the peer to be shut down. |
defer lock.Unlock() | ||
defer os.RemoveAll(lockPath) |
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.
I think that your intent was the following. The defers
are executed in reverse order.
defer lock.Unlock() | |
defer os.RemoveAll(lockPath) | |
defer func(){ | |
lock.Unlock() | |
os.RemoveAll(lockPath) | |
}() |
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.
Approving with a minor comment that can be fixed later.
… from a channel (hyperledger#2769) This change adds a Viper cobra.Command to unjoin the peer from a specified channel. Signed-off-by: Josh Kneubuhl <jkneubuh@us.ibm.com>
… from a channel (#2769) This change adds a Viper cobra.Command to unjoin the peer from a specified channel. Signed-off-by: Josh Kneubuhl <jkneubuh@us.ibm.com>
Type of change
Description
This introduces a transientstore.Delete(ledgerID) routine to assist with the bookkeeping while unjoining a peer from a channel. Before removing the transient storage, the store is marked as UNDER_DELETION in a system leveldb, providing an opportunity to recover from a failed deletion at the next peer initialization.
Signed-off-by: Josh Kneubuhl jkneubuh@us.ibm.com
Additional details
Related issues
Resolves #2786