-
Notifications
You must be signed in to change notification settings - Fork 20.5k
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
cmd, core, eth: journal local transactions to disk #14784
Conversation
abc68cf
to
8a6e8c0
Compare
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.
Code looks OK, but I can imagine this breaking if many transactions are sent. Another thing to think about is how we could make this feature work with the light client.
Maybe the journal could be moved to its own object so it can send transactions into any pool, not just core.TxPool.
Why would this break anything if many transactions are sent? The journal is only ever reprocessed on startup, otherwise it's just overwritten every once in a while. |
8a6e8c0
to
c18e43a
Compare
c18e43a
to
bb2cdf8
Compare
@fjl @Arachnid PTAL. I've separated out the tx journal into its own type. Currently the tx pool contains the journal, but the journal itself is not aware of the pool:
I can look into the light pool in a followup PR. In all honesty I'd rather just use this pool, but if that's not possible, I can make any adjustments needed to get the journal in there too. |
* core: reduce txpool event loop goroutines and sync structs * cmd, core, eth: journal local transactions to disk * core: journal replacement pending transactions too * core: separate transaction journal from pool
This PR adds a disk journal to the transaction pool to back up local transactions. Upon startup, the contents of the journal are merged into the transaction pool, each transaction (and inherently sender address) marked as local. After that on startup, and every hour (configurable via cli) the current contents of the transaction pool are written out into a replacement journal and moved in place of the old one.
During the hour between the journal regeneration, the current journal is kept open append-only, and any arriving local transaction is injected into it.