-
Notifications
You must be signed in to change notification settings - Fork 69
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
Conversation
tasks := toTasks(reqs) | ||
toExecute := tasks | ||
for len(toExecute) > 0 { | ||
for !allValidated(tasks) { |
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.
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
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.
There's no race because this validateAll is blocking.
tasks/scheduler.go
Outdated
|
||
// validated tasks can become unvalidated if an earlier re-run task now conflicts | ||
case statusExecuted, statusValidated: | ||
conflicts := s.findConflicts(tasks[i]) |
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.
isnt this just resulting in all the validations being performed sequentially as opposed to concurrently?
Codecov Report
Additional details and impacted files@@ 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
|
panic("not implemented") | ||
} | ||
|
||
func (store *VersionIndexedStore) UpdateIterateSet(iterationTracker iterationTracker) { |
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.
wasnt this already present from occ-main, or is the diff highlight just weird because of merge conflict resolution
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 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 | ||
} |
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.
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
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.
that's right, it remains as executed and not returned for re-execution, and therefore is eligible for re-validation
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
Describe your changes and provide context
Testing performed to validate your change