-
Notifications
You must be signed in to change notification settings - Fork 54
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
fix: Improve DAG sync with highly concurrent updates #1031
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1031 +/- ##
===========================================
+ Coverage 57.79% 57.82% +0.02%
===========================================
Files 173 173
Lines 19462 19495 +33
===========================================
+ Hits 11249 11273 +24
- Misses 7223 7232 +9
Partials 990 990
|
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.
A single pretty basic item is needed to change. Made a quick note aswell.
// Do not use the first byte of the current value in the comparison. | ||
// It's metadata that will falsify the result. | ||
if len(curValue) > 0 { | ||
curValue = curValue[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.
This isn't exceptionally important. It can stay since technically its more accurate, but it wouldn't change the comparison either way, since its s a byte of metadata that corresponds to the CRDT type, which only get compared within the same type, so it does technically canel itself out.
But yes, technically this is more accurate, just wanted to add some insight.
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.
It actually fails in Andy's PR if this is not done.
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.
ohhh, yes you are right. I see. Thanks for the clarification.
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 was going to ask @fredcarle have you tested this using the tests in my PR? How do you know this PR makes a tangible improvement?
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 have yes. With a couple minor changes. Everything passes as it should.
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.
Nice that's awesome - cheers Fred
net/process.go
Outdated
// TODO: Implement better transaction retry mechanics | ||
// Github issue #1028 | ||
for { |
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.
suggestion: In the short term, can we apply a (perhaps configurable/option) limit to the number of retry attempts, instead of "infinite". Its unlikely to spin forever trying and constantly failing to commit, but just for santy / cleanlyness
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.
Absolutely. Will do.
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.
Minor suggestion.
net/process.go
Outdated
logging.NewKV("DocKey", dockey), | ||
logging.NewKV("CID", c), | ||
) | ||
height := delta.GetPriority() |
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.
todo: Move this below line 89
or do the suggestion on line 90
.
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.
This is existing code that was simply moved inside a for loop. Do really want me to make the change even if it's unrelated to the the fix? Same would apply for your suggestion bellow.
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 do it in a separate commit, you are touching this part of the code anyways and is a one liner.
This isn't worth making an issue for and I doubt we will remember to improve this.
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.
Sounds good. I just wanted to know your opinion on that situation :)
net/process.go
Outdated
) | ||
height := delta.GetPriority() | ||
ng := p.createNodeGetter(crdt, getter) | ||
cids, err := crdt.Clock().ProcessNode(ctx, ng, c, height, delta, nd) |
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.
suggestion:
cids, err := crdt.Clock().ProcessNode(ctx, ng, c, height, delta, nd) | |
cids, err := crdt.Clock().ProcessNode(ctx, ng, c, delta.GetPriority(), delta, nd) |
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.
Thanks Fred, looks good to me so long as there is some protection added against the infinite loop that John flagged :)
e129f6e
to
c949565
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. Minor suggestions and nitpicks, can change/merge as you see fit!
f92fc30
to
a856805
Compare
Relevant issue(s) Resolves #1029 Resolves #1030 Description This PR resolves the eventual consistency bug when highly concurrent updates would cause the DAG syncer to fail reaching consistency. It also adds a simple retry mechanic to avoid sync issues when there is a transaction conflict on the head store.
) Relevant issue(s) Resolves sourcenetwork#1029 Resolves sourcenetwork#1030 Description This PR resolves the eventual consistency bug when highly concurrent updates would cause the DAG syncer to fail reaching consistency. It also adds a simple retry mechanic to avoid sync issues when there is a transaction conflict on the head store.
Relevant issue(s)
Resolves #1029
Resolves #1030
Description
This PR resolves the eventual consistency bug when highly concurrent updates would cause the DAG syncer to fail reaching consistency. It also adds a simple retry mechanic to avoid sync issues when there is a transaction conflict on the head store.
Tasks
How has this been tested?
make test
Specify the platform(s) on which this was tested: