Skip to content
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

[occ] Add scheduler logic for validation #336

Merged
merged 8 commits into from
Oct 19, 2023
Merged

Conversation

stevenlanders
Copy link
Contributor

@stevenlanders stevenlanders commented Oct 18, 2023

Describe your changes and provide context

  • This was copied from [occ] Add validation logic to scheduler #332 which became unwieldy due to commit history (merges/rebases)
  • Adds scheduler logic for validation
  • In this initial version it completes all executions then performs validations (which feed retries)
    • Once we start benchmarking we can make performance improvements to this
  • Retries tasks that fail validation and have no dependencies

Testing performed to validate your change

  • Scheduler Test verifies multi-worker with conflicts

@stevenlanders stevenlanders changed the title [OCC] Add scheduler logic for validation [occ] Add scheduler logic for validation Oct 18, 2023
server/mock/store.go Outdated Show resolved Hide resolved
store/multiversion/store.go Outdated Show resolved Hide resolved
tasks/scheduler.go Outdated Show resolved Hide resolved
tasks/scheduler.go Show resolved Hide resolved
tasks := toTasks(reqs)
toExecute := tasks
for len(toExecute) > 0 {
for !allValidated(tasks) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible for a race condition to occur where all tasks are validated? for example, if TX 3 is valid, and TX 1 finishes execution, and needs to trigger revalidation for TX 3, but TX 1 finishes validation slightly faster, so momentarily theyr all in a valid state? would this be a possible situation in which TX 3 is truly invalid based on the retriggered validation, but the race allows exiting the loop? maybe validateAll is blocking for the loop, so the allValidated won't be evaluated then? not sure

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no race because this validateAll is blocking.


// validated tasks can become unvalidated if an earlier re-run task now conflicts
case statusExecuted, statusValidated:
conflicts := s.findConflicts(tasks[i])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isnt this just resulting in all the validations being performed sequentially as opposed to concurrently?

@codecov
Copy link

codecov bot commented Oct 19, 2023

Codecov Report

Merging #336 (bf31fb8) into occ-main (b34d61c) will increase coverage by 0.04%.
The diff coverage is 62.50%.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff              @@
##           occ-main     #336      +/-   ##
============================================
+ Coverage     56.05%   56.09%   +0.04%     
============================================
  Files           627      627              
  Lines         52638    52753     +115     
============================================
+ Hits          29505    29591      +86     
- Misses        21032    21060      +28     
- Partials       2101     2102       +1     
Files Coverage Δ
baseapp/abci.go 54.27% <ø> (+1.65%) ⬆️
store/types/store.go 68.75% <ø> (ø)
store/multiversion/store.go 98.51% <0.00%> (-0.74%) ⬇️
server/mock/store.go 17.27% <0.00%> (-0.66%) ⬇️
store/multiversion/mvkv.go 97.15% <0.00%> (-2.85%) ⬇️
store/rootmulti/store.go 71.73% <0.00%> (-0.75%) ⬇️
store/cachemulti/store.go 7.54% <0.00%> (-0.88%) ⬇️
tasks/scheduler.go 80.52% <79.64%> (+4.79%) ⬆️

... and 1 file with indirect coverage changes

panic("not implemented")
}

func (store *VersionIndexedStore) UpdateIterateSet(iterationTracker iterationTracker) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasnt this already present from occ-main, or is the diff highlight just weird because of merge conflict resolution

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line doesn't seem to show up in the overall diff, just in the commit itself (a merge from occ-main).

tasks[i].Status = statusWaiting
}
} else {
// no conflicts means this task is validated
} else if len(conflicts) == 0 {
tasks[i].Status = statusValidated
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the case where we are valid but have conflicts, does the task states stay as executed then? (just want to make sure my understanding is correct

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's right, it remains as executed and not returned for re-execution, and therefore is eligible for re-validation

@stevenlanders stevenlanders merged commit 0aebbc9 into occ-main Oct 19, 2023
15 checks passed
@stevenlanders stevenlanders deleted the add-scheduler-logic branch October 19, 2023 17:41
udpatil pushed a commit that referenced this pull request Jan 2, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 8, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 18, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 18, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 25, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 31, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
codchen pushed a commit that referenced this pull request Feb 6, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Feb 27, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Mar 1, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants