Adds Batch client connection and async RPC calls to the bitcoind client#1
Adds Batch client connection and async RPC calls to the bitcoind client#1Vib-UX wants to merge 8 commits into
Conversation
guggero
left a comment
There was a problem hiding this comment.
Looks pretty good! Mostly style nits, functionality looks to there 👍
There was a problem hiding this comment.
Nice work @Vib-UX ⚡ One general comment I can add is to please add some more detail to your commit messages. In general a good commit message is similar to what's describe in this doc:https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#model-git-commit-messages
Obviously it's not a requirement, but a good practice. At a minimum add some short description about what your commit changes, eg. packagename: adding a new shiny func to achieve some goals.
Looking forward for some test coverage as well :)
ef5c3f5 to
1a97548
Compare
a457655 to
7045f44
Compare
bhandras
left a comment
There was a problem hiding this comment.
Great work! Getting very close. RescanBlocks() needs some more fixing but other than that almost good to go.
760fa75 to
a13d267
Compare
8aecdbc to
3b15834
Compare
| // TestBitcoindRescanBlocks ensures that we correctly retrieve the required details | ||
| // for the watched txn. | ||
| func TestBitcoindRescanBlocks(t *testing.T) { | ||
| testBitcoindRescanBlocks(t, true) |
There was a problem hiding this comment.
nit: can create a subtest here with:
t.Run(fmt.Sprintf("rpcpoll=true"), func(t *testing.T) { ... }) etc
|
Actually one last minute comment that maybe needs more work: it is a bit unfortunate that we need to add back old code in order to test expectations, perhaps a better way would be to instead check the output of the new batched call since we know what the output should look like. Otherwise there'll always remain some unused code as part of the public interface that we'll never use. Alternatively you can also rename the "Old" functions as "Sync", meaning they're non batched, slow sequential calls. Also what do you think @guggero ? |
The updated testcoverage removes dependency from the previous Sync functions making it redundant. It was earlier there to compare speedup. |
Just jumping in to answer the question, I'm probably lacking most of the context of the previous discussion. But I'd generally not rename any existing functions, so other users ( |
Yeah maybe best to keep existing functionality and unrenamed. However since the new functionality is not exactly the same semantics as when using the "Async" versions of the RPC API, we could name them "Batched" perhaps to refer that it is doing batched calls under the hood. |
556f769 to
a6ba11e
Compare
bhandras
left a comment
There was a problem hiding this comment.
LGTM, just a few nits remain, great work! 🎉 Make sure to add a detailed description when you open the pull request against the main repo! 🚀
| func (c *BitcoindConn) GetBlocksBatch( | ||
| hashes []*chainhash.Hash) ([]*wire.MsgBlock, error) { | ||
|
|
||
| batchRequest := make( |
There was a problem hiding this comment.
nit: batchRequest could actually just be a slice, no need to key it with the hashes since we always iterate on hashes.
|
|
||
| // requests map will store rpcclient.FutureGetBlockHeaderVerboseResult | ||
| // for each blockHash. | ||
| requests := make( |
There was a problem hiding this comment.
nit: i think this also could just be an array since we always iterate on blockHashes.
| // a FilterBlocksReponse for the first block containing a matching address. | ||
| // If no matches are found in the range of blocks requested, the returned | ||
| // response will be nil. | ||
|
|
| require.NoError(t, err) | ||
| msgBlocksStandard = append(msgBlocksStandard, msgBlock) | ||
| } | ||
| msgBlocksBatchClient, err := bitcoindClient.GetBlocksBatch(blockHashes) |
There was a problem hiding this comment.
nit: add an extra nl after the for block
| // linearly with GetBlock() (store the result for each GetBlock() in a | ||
| // slice) further also try to retrieve blocks in batch with GetBlocksBatch(). | ||
| // At last will compare the results from both which should be equal. | ||
| if _, err := miner.Client.Generate(5); err != nil { |
There was a problem hiding this comment.
nit: I think it'd be better to generate something like 2x15 + some blocks to test that we do create multiple batches correctly.
|
I think it makes sense to open the PR against the main repo now. I'll happily do a review there. Is that okay for everyone? |
Yeah, sure. Actually we also just agree with @Vib-UX to open it against upstream, since the PR is quite ready as is. |
759043b to
7f29aa8
Compare
This commit adds a batch client connection and async RPC calls to the bitcoind client which will enable batching multiple requests speeding up operations by reducing round trips.
This will leverage the updated batch client to fetch multiple blocks in one go which can speed up rescan and filter blocks.
Both RescanBlocksBatched() and FilterBlocksBatched() leverages GetBlocksBatch() which works with the updated batch client for speed ups.
Testcoverage to ensure that GetBlocksBatch() which leverages batchAPI works as expected with enhanced performance.
Testcoverage to ensure that RescanBlocksBatched() which leverages updated batchAPI for scanning the chain works as expected with enhanced performance.
Testcoverage to ensure that FilterBlocksBatched() which leverages batchAPI for scanning the chain works as expected with enhanced performance.

PR serves in relation to fixing issue 5041
With this PR we enable batch client connection and async RPC calls to the bitcoind client providing testcoverages for the same. This helps us in batching the required requests needed for speeding up operations by reducing round trips.
Pull Request Checklist
Testing
Code Style and Documentation
📝 Please see our Contribution Guidelines for further guidance.