Skip to content
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

Mempool: Allow for dynamically adjusting the capacity #1498

Closed
intricate opened this issue Jan 23, 2020 · 0 comments
Closed

Mempool: Allow for dynamically adjusting the capacity #1498

intricate opened this issue Jan 23, 2020 · 0 comments
Assignees
Labels
consensus issues related to ouroboros-consensus mempool

Comments

@intricate
Copy link
Contributor

As of #1468, by default (unless overridden in the NodeArgs), the mempool capacity is calculated as 2x that of the maximum block size from the protocol parameters in the ledger.

However, the mempool capacity is only calculated once at node initialization time which means that, if the ledger's max block size changes during the node's runtime, the mempool capacity will not be automatically recalculated to reflect this. The mempool capacity would only be calculated again upon restarting the node.

See #1468 (review) for discussion WRT this.

@intricate intricate added consensus issues related to ouroboros-consensus mempool priority low labels Jan 23, 2020
@intricate intricate self-assigned this Jan 23, 2020
mrBliss added a commit that referenced this issue May 27, 2020
Fixes #1498.

The capacity of the Mempool can be manually overridden using
'MempoolCapacityBytesOverride'. When not overridden, the default capacity is
computed as 2x the maximum transaction capacity of a block, which is derived
from the protocol parameters in the ledger state.

Previously, this default capacity was computed *once* based on the ledger
state at the time of starting the Mempool. So when the maximum transaction
capacity of a block changes in the ledger, a restart of the node was needed to
let the Mempool update its capacity accordingly.

In this commit, we make it dynamic: we derive it from the ledger that the
Mempool watches. When the capacity shrinks, we don't remove transactions to
satisfy the new capacity, but we treat the Mempool as if it is *at* capacity.
This means no new transactions are admitted until some have been invalidated
by an update to the ledger.
mrBliss added a commit that referenced this issue May 27, 2020
Fixes #1498.

The capacity of the Mempool can be manually overridden using
'MempoolCapacityBytesOverride'. When not overridden, the default capacity is
computed as 2x the maximum transaction capacity of a block, which is derived
from the protocol parameters in the ledger state.

Previously, this default capacity was computed *once* based on the ledger
state at the time of starting the Mempool. So when the maximum transaction
capacity of a block changes in the ledger, a restart of the node was needed to
let the Mempool update its capacity accordingly.

In this commit, we make it dynamic: we derive it from the ledger that the
Mempool watches. When the capacity shrinks, we don't remove transactions to
satisfy the new capacity, but we treat the Mempool as if it is *at* capacity.
This means no new transactions are admitted until some have been invalidated
by an update to the ledger.
mrBliss added a commit that referenced this issue May 27, 2020
Fixes #1498.

The capacity of the Mempool can be manually overridden using
'MempoolCapacityBytesOverride'. When not overridden, the default capacity is
computed as 2x the maximum transaction capacity of a block, which is derived
from the protocol parameters in the ledger state.

Previously, this default capacity was computed *once* based on the ledger
state at the time of starting the Mempool. So when the maximum transaction
capacity of a block changes in the ledger, a restart of the node was needed to
let the Mempool update its capacity accordingly.

In this commit, we make it dynamic: we derive it from the ledger that the
Mempool watches. When the capacity shrinks, we don't remove transactions to
satisfy the new capacity, but we treat the Mempool as if it is *at* capacity.
This means no new transactions are admitted until some have been invalidated
by an update to the ledger.
mrBliss added a commit that referenced this issue May 27, 2020
Fixes #1498.

The capacity of the Mempool can be manually overridden using
'MempoolCapacityBytesOverride'. When not overridden, the default capacity is
computed as 2x the maximum transaction capacity of a block, which is derived
from the protocol parameters in the ledger state.

Previously, this default capacity was computed *once* based on the ledger
state at the time of starting the Mempool. So when the maximum transaction
capacity of a block changes in the ledger, a restart of the node was needed to
let the Mempool update its capacity accordingly.

In this commit, we make it dynamic: we derive it from the ledger that the
Mempool watches. When the capacity shrinks, we don't remove transactions to
satisfy the new capacity, but we treat the Mempool as if it is *at* capacity.
This means no new transactions are admitted until some have been invalidated
by an update to the ledger.
mrBliss added a commit that referenced this issue May 27, 2020
Fixes #1498.

The capacity of the Mempool can be manually overridden using
'MempoolCapacityBytesOverride'. When not overridden, the default capacity is
computed as 2x the maximum transaction capacity of a block, which is derived
from the protocol parameters in the ledger state.

Previously, this default capacity was computed *once* based on the ledger
state at the time of starting the Mempool. So when the maximum transaction
capacity of a block changes in the ledger, a restart of the node was needed to
let the Mempool update its capacity accordingly.

In this commit, we make it dynamic: we derive it from the ledger that the
Mempool watches. When the capacity shrinks, we don't remove transactions to
satisfy the new capacity, but we treat the Mempool as if it is *at* capacity.
This means no new transactions are admitted until some have been invalidated
by an update to the ledger.
@iohk-bors iohk-bors bot closed this as completed in 9e2cf9d May 27, 2020
@mrBliss mrBliss added this to the S14 2020-06-04 milestone May 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus issues related to ouroboros-consensus mempool
Projects
None yet
Development

No branches or pull requests

2 participants