-
Notifications
You must be signed in to change notification settings - Fork 1.6k
fet(event): optimize event service to obtain transaction information #6443
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
Conversation
yanghang8612
left a comment
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.
LGTM
| endNum = manager.getDynamicPropertiesStore().getLatestSolidifiedBlockNum(); | ||
| } | ||
| initEventService(manager.getChainBaseManager().getBlockIdByNum(endNum)); | ||
| long startNum = endNum == 0 ? 0 : endNum - 1; |
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.
If now solidifiedBlockNum is 100, but the startSyncBlockNum in config is 1000, it still start writing events from 99?
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.
Will write from 100, and you need to configure startSyncBlockNum reasonably.
| for (int i = 0; i < block.getTransactions().size(); i++) { | ||
| Protocol.Transaction tx = block.getInstance().getTransactions(i); | ||
| Protocol.TransactionInfo txInfo = result.getInstance().getTransactioninfo(i); | ||
| Protocol.TransactionInfo txInfo = list.getTransactionInfo(i); |
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.
if list get from getTransactionInfoByBlockNum is empty, or list.getTransactionInfoCount() != block.getTransactions().size(), is there any problem?
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.
No problem, this situation does not exist, otherwise the data is inconsistent.
…ronprotocol#6443) * feat(event): solve the problem of concurrent access to a single SR * feat(event): solve the concurrency problem of single SR obtaining solid ID
What does this PR do?
Optimize event service to obtain transaction information.
Why are these changes required?
This PR has been tested by:
Follow up
Extra details