-
Notifications
You must be signed in to change notification settings - Fork 5
fix: concurrency insert between pending and delivered #467
Conversation
707fe93
to
4217661
Compare
2718df1
to
aacf1b1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #467 +/- ##
==========================================
- Coverage 71.87% 71.69% -0.18%
==========================================
Files 225 227 +2
Lines 12675 12743 +68
==========================================
+ Hits 9110 9136 +26
- Misses 3565 3607 +42 ☔ View full report in Codecov by Sentry. |
7e0db52
to
0dc637d
Compare
4217661
to
22cf5ba
Compare
93e9db3
to
5b1ad56
Compare
89f59ca
to
ae3e1b5
Compare
5b1ad56
to
b9d7dd6
Compare
5a97b89
to
dc67f92
Compare
b9d7dd6
to
13b8229
Compare
dc67f92
to
faf394d
Compare
13b8229
to
4ad75da
Compare
b0166e1
to
e47bbfa
Compare
bc6d75c
to
fc3427e
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, and thank you for the high quality comments explaining what is going on.
Beyond this PR, I think this need for strong synchronization is unfortunate. It makes the code less clear and introduces delays that could harm performance. Not sure how we could do better but I'll try to give it some thought. I have a gut feeling that treating pending and delivered certificates separately is part of the problem, but I'll have to think more on this.
Signed-off-by: Simon Paitrault <[email protected]>
Signed-off-by: Simon Paitrault <[email protected]>
Signed-off-by: Simon Paitrault <[email protected]>
Signed-off-by: Simon Paitrault <[email protected]>
a440b18
to
6b299e1
Compare
Signed-off-by: Simon Paitrault <[email protected]>
6b299e1
to
736c877
Compare
Signed-off-by: Simon Paitrault <[email protected]>
Signed-off-by: Simon Paitrault <[email protected]>
93b135a
to
4747f46
Compare
Signed-off-by: Simon Paitrault <[email protected]>
ef29cc4
to
ab62149
Compare
Signed-off-by: Simon Paitrault <[email protected]>
Signed-off-by: Simon Paitrault <[email protected]>
Description
This PR is covering a corner case which involve the delivery of a prev certificate and a child certificate.
The scenario is this one:
prev
certificate (C1
) has been delivered (by the broadcast) and need to be persistedThe persist method will hold a lock while performing multiple insert/delete to avoid
insert race condition.
C2
) which haveC1
asprev_id
.C2
is looking at the storage to find if theprev_id
C1
is delivered but find nothing asthe
persist
method is still working at creating theWriteBatch
. It led the node to putC2
in theprecedence_pool
waiting forC1
to be delivered while it is in fact alreadydelivered.
To avoid that and as a first step, when trying to insert a certificate in the pending pool,
The node will try to acquire a lock guard on the certificate but also on the prev_id.
PR Checklist: