-
Notifications
You must be signed in to change notification settings - Fork 305
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
Make blocks cache locked in Store when used + minor cleanup #7594
Conversation
@@ -37,6 +38,22 @@ static BlockProvider fromDynamicMap(Supplier<Map<Bytes32, SignedBeaconBlock>> ma | |||
return (roots) -> fromMap(mapSupplier.get()).getBlocks(roots); | |||
} | |||
|
|||
static BlockProvider fromMapWithLock( |
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.
should probably add a test case
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 you asked for it, I made all stupidly wrong, fixed
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 did the wrong thing again, thinking how to do it correctly
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.
So my understanding on this is:
- We should remove
SafeFuture.supplyAsync()
to avoid such errors, noone was using it, and we should use our own AsyncRunner whenever it's needed - In this case we should use our AsyncRunner
- We should also use it in Store methods that use locks and return SafeFuture otherwise they are synchronously locked (
retrieveFinalizedCheckpointAndState
,createStateGenerationTask
) - It will require rework of many
Store
tests
What do you think?
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 we could raise a ticket for that cleanup, but probably not worth it now, it'd be a big distraction if its used a bunch in tests...
Using async here though would make sense so we dont add to the problem...
} | ||
}) | ||
.ifExceptionGetsHereRaiseABug(); | ||
assertThat(isNotBlocked.await(1, TimeUnit.SECONDS)).isFalse(); |
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.
even something small like 100ms should be plenty here?
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.
Sure
… own AsyncRunner when needed
@rolfyone finished, ready for review
|
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
Disabled windows test for a while, will check on my local windows |
Fixed flakiness with 50a3be1 |
PR Description
I've noticed that blocks are not actually locked if we go in block provider, after inMemory lookup in
retrieveSignedBlock
(it could actually changed between) and when directly usingblockProvider
, so tried to fix it.Fixed Issue(s)
Documentation
doc-change-required
label to this PR if updates are required.Changelog