-
Notifications
You must be signed in to change notification settings - Fork 71
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
Add genesis transactions caching #243
Add genesis transactions caching #243
Conversation
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
Andrew — could you provide details on how this works? Presumably we would need a JavaScript wrapper update as well. |
@cvarjao @wadeking98 — FYI. @berendsliedrecht — any chance you could make the update to the JavaScript wrapper? This would be good to get into the AFJ. |
Signed-off-by: Andrew Whitehead <cywolf@gmail.com>
I did some quick testing of the different versions, performing a refresh on Sovrin Buildernet from the Github version of the genesis transactions, averaged over 5 runs. For the current release (0.4.0): 1.61s |
Nice!! It sure doesn’t explain 2 minutes for an issue credentialm but it certainly is way better! I was wondering if we could have a minimalist script that use Indy VDR and runs some sort of reading test script against different ledgers. It would be really nice to have that so that it could be run when we want to investigate an issue with a given ledger. And it could demonstrate “best practices” for a caller using Indy VDR. What do you think? |
@swcurran Yes, that sounds useful. There's some integration tests in this repo but they might need to be generalized to test against a random ledger. It might be a bit limited given that we don't know there are any registered objects of different types, like revocation registries, but it can certainly test connectivity and fetching transactions (and optionally writing as well). |
This PR adds a new FFI method (and Python binding) to set the cache directory to use. When the cache directory is set, the library will automatically store the latest transactions for a given root hash and fetch them when creating a new pool. This means that as long as the same genesis transactions are passed in (via a string or file), it should be able to find the latest copy.
After the initial refresh of a pool, or if the transactions are cached, the library will also use a consensus
GET_TXN
request to check the latest pool state. This can be faster than the traditional status request as it will short-circuit after a single valid state proof, instead of attempting to contact all of the nodes.