-
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
Fix block data cleaning from pools #2259
Conversation
SebastianMarian
commented
Aug 30, 2020
- Canceled the removal of block data at the commit time as this approach was forgotten here and its scope was to test an old issue which was proven later to be from somewhere else. As now, there are situations when block data (miniblocks and transactions) are intentionally broadcast with delay, the call of the removeBlockDataFromPool method at commit time, could remove from pool only partial data. Because of this, when the cleanupPools method is called for the headers behind final, the already removed block data at the commit time for earlier blocks, broke some links between all the components from these blocks and they could not be removed anymore completely from pools.
…ach was forgotten here and its scope was to test an old issue which was proven later to be from somewhere else. As now, there are situations when block data (miniblocks and transactions) are intentionally broadcast with delay, the call of the removeBlockDataFromPool method at commit time, could remove from pool only partial data. Because of this, when the cleanupPools method is called for the headers behind final, the already removed block data at the commit time for earlier blocks, broke some links between all the components from these blocks and they could not be removed anymore completely from pools.
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 failed
518a6bf
cmd/node/config/config.toml
Outdated
@@ -541,7 +541,7 @@ | |||
|
|||
[BlockSizeThrottleConfig] | |||
MinSizeInBytes = 104857 # 104857 is 10% from 1MB | |||
MaxSizeInBytes = 943718 # 943718 is 90% from 1MB | |||
MaxSizeInBytes = 891289 # 943718 is 85% from 1MB |
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.
👍
…uted transaction is of type smart contract call/deploy - made p2p `buffer too large` error message carry more info - reverted throttling config changes
9e0cbba
@@ -961,7 +961,12 @@ func (txs *transactions) createAndProcessMiniBlocksFromMe( | |||
} | |||
|
|||
miniBlock.TxHashes = append(miniBlock.TxHashes, txHash) | |||
txs.blockSizeComputation.AddNumTxs(1) | |||
numTxs := 1 | |||
if core.IsSmartContractAddress(tx.RcvAddr) { |
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.
this is not the correct way to resolve it. Add blockSizeComputation component to smart contract result post processor and call AddNumTxs there when new cross shard SCRs are generated. It is not ensured that one tx = one scr
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.
When we reach the postprocessor it is already too late as the transactions are already executed and we need to include the scr(s) as well. Indeed, it is not ensured that one tx = one scr but at least it will estimate 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.
Actually you will have nothing in post processor when you create a miniblock from me to meta with 27k stake SC calls. But at destination, in this case in meta, could result 54k txs (from which 27k are SCR). Because you need to process at least one mb completely this could result in a stuck situation. So, you also need to multiply at source, with 2 or more (in terms of size, depending of how many SCR could exist), all the SC calls when you create mbs from me. I think that this situation on normal cases should be solved by gas limit and in case of an invalid SC call, adding only one additional tx which simulates the scr created at destination, should be enough as in this case would be only one SCR for each invalid SC call?
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.
Added block size computation taking in consideration also the post process mbs and txs when creating mbs dest me
…st processor miniblocks and transactions
…st processor miniblocks and transactions
…ls' into Fix-block-data-cleaning-from-pools # Conflicts: # process/block/preprocess/transactions.go
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.
add unit test
txs.blockSizeComputation.AddNumTxs(1) | ||
txs.blockSizeComputation.AddNumTxs(numScCalls) |
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.
numScCalls here is always 1. call txs.blockSizeComputation.AddNumTxs(1) instead of numSCCalls++. Although this protection should be only for cross shard and per shard.
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.
Done
process/coordinator/process.go
Outdated
|
||
mbs := interimProc.CreateAllInterMiniBlocks() | ||
for _, mb := range mbs { | ||
numTxs += len(mb.TxHashes) |
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.
do not add intra shard miniblocks.
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.
Refactored
numTxs := 0 | ||
numCrossShardScCalls := 0 | ||
|
||
allTxs := make(map[string]data.TransactionHandler) |
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.
some unit tests would have been great
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.
Would be added of course. Just waiting for the system test results
…ers to how many txs of sc call type, could be included in one block
…ers to how many txs of sc call type, could be included in one block
…ls' into Fix-block-data-cleaning-from-pools
core/constants.go
Outdated
@@ -505,3 +505,7 @@ const MaxWaitingTimeToReceiveRequestedItem = 5 * time.Second | |||
// DefaultLogProfileIdentifier represents the default log profile used when the logviewer/termui applications do not | |||
// need to change the current logging profile | |||
const DefaultLogProfileIdentifier = "[default log profile]" | |||
|
|||
// MultiplyFactorForScCall specifies the multiply factor, in terms of number, which should be used for how many sc calls | |||
// could be included in one block (normal txs -> aprox. 27000, sc calls -> aprox. 2700 with value of 9 set below) |
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.
comment or value need to be adjusted
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.
done
{numNewMiniBlocks: 1, numNewTxs: 27757, expected: true, name: "with miniblocks 1 and txs 20078"}, | ||
{numNewMiniBlocks: 2, numNewTxs: 27756, expected: true, name: "with miniblocks 2 and txs 20077"}, | ||
{numNewMiniBlocks: 1, numNewTxs: 27756, expected: false, name: "with miniblocks 1 and txs 27756"}, | ||
{numNewMiniBlocks: 1, numNewTxs: 27757, expected: true, name: "with miniblocks 1 and txs 27757"}, |
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.
👍
@@ -476,6 +477,43 @@ func (scr *smartContractResults) ProcessMiniBlock(miniBlock *block.MiniBlock, ha | |||
&totalGasConsumedInSelfShard) | |||
|
|||
if err != nil { | |||
//TODO: Remove this after testing |
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't remove this as it is used for the debug print L499
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.
This was added to serves the prints and also the prints would been removed now
@@ -145,6 +151,13 @@ func (vip *validatorInfoPreprocessor) ProcessMiniBlock(miniBlock *block.MiniBloc | |||
return nil, process.ErrValidatorInfoMiniBlockNotFromMeta | |||
} | |||
|
|||
if vip.blockSizeComputation.IsMaxBlockSizeWithoutThrottleReached(1, len(miniBlock.TxHashes)) { |
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.
We need another function in the blocksize estimator that will better handle the peer changes as those are not hashes. cc @sasurobert
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.
Those are taken as it is. It is hard to estimate what is the actual value
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.
Please add a TODO to fix the estimator. It is not complicated to do so in a separate PR.
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.
The good part is that until then we can reduce if needed the MaxSizeInBytes from [BlockSizeThrottleConfig] in config.toml to 85% from 90% and in this way we should avoid any kind of "message too large" from p2p
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.
CreateSCRIfError is wrongly constructed right now. It is an old code, which is not up to date. Will fix it in separate PR.
@@ -145,6 +151,13 @@ func (vip *validatorInfoPreprocessor) ProcessMiniBlock(miniBlock *block.MiniBloc | |||
return nil, process.ErrValidatorInfoMiniBlockNotFromMeta | |||
} | |||
|
|||
if vip.blockSizeComputation.IsMaxBlockSizeWithoutThrottleReached(1, len(miniBlock.TxHashes)) { |
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.
Those are taken as it is. It is hard to estimate what is the actual value
a56c36e
if !firstCrossShardScCallFound { | ||
numNewMiniBlocks++ | ||
} | ||
numNewTxs += 1 * core.MultiplyFactorForScCall |
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.
1*core.MultiplyFactorForScCall
why 1*x instead of simply x ?
Is it supposed to be changed later to a different value? then use a constant.
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 just kept an old pattern when 1 was a variable named numTxs. I will change.
txs.blockSizeComputation.AddNumMiniBlocks(1) | ||
} | ||
//we need to increment this as to account for the corresponding SCR hash | ||
txs.blockSizeComputation.AddNumTxs(1 * core.MultiplyFactorForScCall) |
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.
1*core.MultiplyFactorForScCall ?
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 just kept an old pattern when 1 was a variable named numTxs. I will change.
ec6008a
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.