-
Notifications
You must be signed in to change notification settings - Fork 198
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
[Minor bug / minor fix] TxPool - fix inconsistent counters (estimators) #1842
Conversation
storage/txcache/txByHashMap.go
Outdated
// we might end up decrementing the counters twice. | ||
// Possible solution: use an "onItemRemoved" callback in the "backingMap" | ||
// to decrement the counters. | ||
tx := item.(*WrappedTransaction) |
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.
You can check for correct type assertion here, so if will be the case in some strange circumstances you will avoid passing nil to line 46 in estimateTxSize method and also to return nil, true in line 49
tx, ok := item.(*WrappedTransaction)
if !ok {
return nil, false
}
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.
Changed. Though, having something other than *WrappedTransaction
in the backingMap
would be a critical bug.
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.
Agreed. But for the sake of uncle Bob :)
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.
System tests passed.
Original conversation in PR 1802.
Fixed some inconsistent counters for senders and transactions within the internal structures of the transactions pool. Inconsistencies could occur in case of high concurrency and / or concurrent removals (eviction plus removal due to commit / finalize). The bug was mostly benign, but if it were, say, thousands of such events, the counters would have become slightly off and therefore could have lead - in extreme cases - to OOM (since eviction would have been based on bad, low counters).
Extra - fixed some linting issues within package
storage/immunitycache
.Details of the fix:
txListBySenderMap.addSender()
: counter is consistent because the function is called undertxListBySenderMap
's global mutextxListBySenderMap.removeSender()
: fixedtxByHashMap.addTx()
: counter is consistent because we use "SetIfAbsent"txByHashMap.removeTx()
: fixed