feat(mempool): incremental recheck #909
Conversation
…mpletion) and into a seperate Cancel function
e87dacf to
9134baf
Compare
| dirtyAccounts: dirtyAccounts, | ||
| events: queuedEvents, | ||
| } | ||
| go pool.runReorg(input) |
Check notice
Code scanning / CodeQL
Spawning a Go routine Note
| func (iq *insertQueue) addTx(tx *ethtypes.Transaction) { | ||
| defer func(t0 time.Time) { | ||
| telemetry.MeasureSince(t0, "expmempool_inserter_add") //nolint:staticcheck // TODO: switch to OpenTelemetry | ||
| }(time.Now()) |
Check warning
Code scanning / CodeQL
Calling the system time Warning
| @@ -417,16 +413,16 @@ | |||
Check warning
Code scanning / CodeQL
Calling the system time Warning
|
|
||
| return NewEVMMempoolIterator( | ||
| evmIterator, | ||
| cosmosIterator, |
Check warning
Code scanning / CodeQL
Calling the system time Warning
| func (c *txCollector) Collect(ctx context.Context, height *big.Int, filter txpool.PendingFilter) map[common.Address][]*txpool.LazyTransaction { | ||
| genesis := big.NewInt(0) | ||
|
|
||
| start := time.Now() |
Check warning
Code scanning / CodeQL
Calling the system time Warning
| done: make(chan struct{}), | ||
| } | ||
|
|
||
| go iq.loop() |
Check notice
Code scanning / CodeQL
Spawning a Go routine Note
Description
This adds the ability for proposals to be created out of txs in the pending pool while the pool is resetting via a new block. Previously, this resetting would hold the lock on the pool for the entire duration of the reset, which would need to call recheck on every tx in the pending pool. This may take multiple seconds, which will block a call to
Pendingand therefore blockPrepareProposal.This PR addresses this by pushing txs into a
txCollectoras they are validated viademoteUnexecutables. Creating a 'snapshot' of the pending txs that have been validated for a height at any given time. This snapshot no longer shares the same global legacypool lock, thus unblockingPrepareProposal's call toPending.This PR also adds functionality where the reorg loop will be cancelled if it is still processing a reset (new block seen), and a new block arrives. This is to prevent the case where
demoteUnexecutablestakes such a long time to process txs that processing the previous height, always takes longer than the timeout the caller is willing to wait inPending, thus preventing any txs from ever making it into a proposal.This PR also addresses an issue existing in
feat/krakatoawhere the chain would essentially slow down heavily once tx load increased. This was due to tx gossip directly callinglegacypool.Addwhich needed to acquire a lock shared with the reorg loop, which may take 5-10s at peak load in order to be released. This would cause a backup of other critical p2p messages, typically resulting in high prevote times. To fix this, ainsertQueuehas been added in order to decouplelegacypool.Addfrom the hot path of p2p message processing.Closes: STACK-2008
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
mainbranch