-
Notifications
You must be signed in to change notification settings - Fork 130
[PAN-2850] Create a transaction pool configuration object #1615
[PAN-2850] Create a transaction pool configuration object #1615
Conversation
final MetricsSystem metricsSystem, | ||
final SyncState syncState, | ||
final int maxTransactionRetentionHours, | ||
final Wei minTransactionGasPrice, |
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.
(Discussion) What about folding minTransactionGasPrice
into TransactionPoolConfiguration
? Or maybe the TransactionPool
also gets access to MiningParams
so that we don't end up duplicating data on 2 different config objects?
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.
Yes it makes sense.
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 mean the second approach where TransactionPool also gets access to MiningParams
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 the PantheonControllerBuilder
passes the minTransactionPrice
to the transactionPool from the MiningParams
final TransactionPool transactionPool =
TransactionPoolFactory.createTransactionPool(
protocolSchedule,
protocolContext,
ethProtocolManager.ethContext(),
clock,
metricsSystem,
syncState,
miningParameters.getMinTransactionGasPrice(),
transactionPoolConfiguration)
SInce it uses only one parameter from the MiningParams i don't think we need to give it access to the whole object now. What do you think ?
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.
🤷♀ Just feels odd to have a config object and then have an additional dangling option. But there's some weirdness with all 3 options really (as is + my 2 alternative suggestions). I think I'm leaning towards passing in the MiningParams
- it makes it more explicit that the transactionPool's behavior is modified by the mining configuration. But I'll leave it up to you.
PR description
Regroup
txPoolMaxSize
,pendingTxRetentionPeriod
,txMessageKeepAliveSeconds
CLI options into oneTransactionPoolConfiguration
object.Fixed Issue(s)