Scheduler doesn't consider dependency changes computed against older build #100
Comments
Merged
msimacek
added a commit
that referenced
this issue
May 24, 2017
When sqla is building query results and sees an object that it already has in its session, it returns that object ignoring the actual row from query result. With that it tries to emulate repeatable read level of isolation. But in koschei, we sometimes need read committed isolation level in order to achieve mutual exclusion of side-effects (fedmsg, build scheduling). Expiring the objects in resolver forces their refresh, avoiding race conditions with scheduler (like described in #100 and #158).
mizdebsk
pushed a commit
that referenced
this issue
Jul 21, 2017
When sqla is building query results and sees an object that it already has in its session, it returns that object ignoring the actual row from query result. With that it tries to emulate repeatable read level of isolation. But in koschei, we sometimes need read committed isolation level in order to achieve mutual exclusion of side-effects (fedmsg, build scheduling). Expiring the objects in resolver forces their refresh, avoiding race conditions with scheduler (like described in #100 and #158).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Few months ago, I added additional check for scheduling based on dependency changes - if the changes were computed against older build than the newest one, they are not considered. The reason for that is that it prevents race conditions that may cause builds being scheduled in quick succession for the same reason.
Example of the race: build 1 has some dependency changes -> resolver starts resolving repo against build 1 -> scheduler schedules a build 2, based on changes against build 1 -> build 2 completes -> resolver persists dependency changes that were computed against build 1 -> scheduler schedules build 3 based on outdated dependency changes that were computed against build 1 again, not build 2
But this check creates another problem - when the last build is unresolved, the dependency changes are computed against older build, but scheduler ignores them, so the package doesn't get priority. This mechanism should be revised to cope with both problems at the same time.
The text was updated successfully, but these errors were encountered: