Feature events api #984
Feature events api #984
Conversation
|
Changes Unknown when pulling 3df1ba3 on feature-events-api into ** on develop**. |
| logger.info("Replaying blocks from " + firstBlock + ", current best block: " + lastBlock); | ||
| int cnt = 0; | ||
| long num = firstBlock; | ||
| while(true) { |
There was a problem hiding this comment.
while (!replayComplete) is better if it does not break the logic (as I can see it does not)
| replayComplete = true; | ||
| break; | ||
| } else { | ||
| long newLastBlock = blockStore.getMaxNumber() - 192; |
There was a problem hiding this comment.
is 192 a magic number? why exactly 192 but not the other one?
|
Changes Unknown when pulling 3ef8f29 on feature-events-api into ** on develop**. |
| protected PendingStateImpl pendingState; | ||
|
|
||
| // txHash => PendingEvent | ||
| protected Map<ByteArrayWrapper, PendingEvent> pendings = new LinkedHashMap<>(); |
There was a problem hiding this comment.
Maybe wrap it by ByteArrayMap for convenience?
There was a problem hiding this comment.
Cool, didn't know about it.
| } | ||
| } | ||
|
|
||
| if (blockSummary.getTotalDifficulty().compareTo(lastTotDiff) > 0) { |
There was a problem hiding this comment.
Isn't it a better idea to supply BlockSummary with ImportStatus to indicate whether imported block is best or not. This small feature might be useful in many other places and save us from keeping this redundant code and data structures
There was a problem hiding this comment.
Good idea, but I'd rather put this logic in BlockSummary, because ImportState couldn't be always kept in BlockSummary, as summary may be null. I'll push this approach and we could discuss it, if it doesn't look ok.
| int txCount = 0; // several transactions are possible withing a single Ethereum Tx | ||
| List<EventData> matchedTxs = new ArrayList<>(); | ||
| for (LogInfo logInfo : receipt.getLogInfoList()) { | ||
| if (contractAddressFilter.matchBloom(logInfo.getBloom()) && |
There was a problem hiding this comment.
Current implementation doesn't allow user to instantiate a listener which does topics filtering out of the box. I think it worth to be extended with that feature.
There was a problem hiding this comment.
Do you think we need such kind of low-level listener in addition to parsed events listener?
|
Changes Unknown when pulling 1c3e173 on feature-events-api into ** on develop**. |
|
Changes Unknown when pulling 673f7e3 on feature-events-api into ** on develop**. |
@mkalinin please take a look
Added events api + block replay
also removed obsolete networks settings