-
Notifications
You must be signed in to change notification settings - Fork 502
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
services/horizon/internal/expingest: Remove orderbook graph from ingestion system #2639
Conversation
490e9bc
to
f037b2e
Compare
f037b2e
to
fbd36c2
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.
LGTM! Just minor comments.
log.WithField("ingestLedger", ingestLedger). | ||
WithField("lastIngestedLedger", lastIngestedLedger). | ||
Info("bumping ingest ledger to next ledger after ingested ledger in db") | ||
ingestLedger = lastIngestedLedger + 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.
Maybe we should transition state?
ingestLedger = lastIngestedLedger + 1 | |
return resume(lastIngestedLedger), nil |
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.
I think it's better as is because at this moment in the code we have the select for update lock. if we transition to the state we need to release the select for update and the next node would need to acquire the select for update lock. I think by bumping the ingestLedger we reduce latency in the ingestion process
const verificationFrequency = time.Hour | ||
const ( | ||
verificationFrequency = time.Hour | ||
updateFrequency = 30 * time.Second |
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.
Can we change it to 5 sec. so it updates with every ledger (on average)?
updateFrequency = 30 * time.Second | |
updateFrequency = 5 * time.Second |
Co-authored-by: Bartek Nowotarski <[email protected]>
…ple ledgers (#2649) Before #2639 we were updating the order book graph via ingestion on every single ledger. The order book graph was implemented with the expectation that you must apply changes for every single ledger and no ledgers should be skipped. However, we can no longer maintain that invariant because now we are applying updates to the order book graph via the OrderBookStream. The OrderBookStream periodically polls for new / updated offers from the Horizon DB. It is possible that ingestion has advanced by more than one ledger since the last time OrderBookStream updated the order book graph. Therefore we must relax the restrictions for how updates are applied to an order book graph. We still require ledgers to be strictly increasing when applying updates to an order book graph. However, now we allow updates to span multiple ledgers. We also allow you to remove an offer which is not present in the order book. Consider the case where you apply updates from ledger x. Let's say the next time we update the order book graph ingestion has already advanced to x+2. It is possible that an offer was created in ledger x+1 and in ledger x+2 we are removing the offer. However, our graph was last updated at ledger x, so when we try to remove the offer which was created in ledger x+1 we will panic unless we deliberately skip over offers which are not present in the order book.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Follow-up to #2630 which removes orderbook graph ingestion.
Why
After #2630 , the horizon ingesting nodes no longer need to maintain an in memory order book. Instead, the request serving horizon instances will populate their order books by polling offers from the horizon db. This polling process is downstream of ingestion.
Known limitations
[ N/A]