Fix race condition when starting DagProcessorAgent #19935
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
boring-cyborg
bot
added
the
area:Scheduler
This was referenced Dec 1, 2021
potiuk
force-pushed
the
fix-race-condition-with-killing-processor-mnager
branch
from
e1adfaa to
067cc80
Compare
potiuk
changed the title
Member
Author
|
Looks really good with all tests green !!! :). Cannot wait to merge it and rebase the last 'stability' one :) |
potiuk
force-pushed
the
fix-race-condition-with-killing-processor-mnager
branch
3 times, most recently
from
fa9587c to
b309675
Compare
ashb
reviewed
Dec 2, 2021
ashb
reviewed
Dec 2, 2021
As described in detail in apache#19860, there was a race condition in starting and terminating DagProcessorAgent that caused us a lot of headeaches with flaky test_scheduler_job failures on our CI and after long investigation, it turned out to be a race condition. Not very likely, but possible to happen in production. The race condition involved starting DagProcessorAgent via multiprocessing, where the first action of the agent was changing the process GID to be the same as PID. If the DagProcessorAgent was terminated quickly (on a busy system) before the process could change the GID, the `reap_process_group` that was supposed to kill the whole group, was failing and the DagProcessorAgent remained running. This problem revealed a wrong behaviour of Airflow in some edge conditions when 'spawn' mode was used for starting the DAG processor Details are described in apache#19934, but this problem will have to be solved differently (avoiding ORM reinitialization during DAG processor starting). This change also moves the tests for `spawn` method out from test_scheduler_job.py (it was a remnant of old Airlfow and it did not really test what it was supposed to test). Instead tests were added for different spawn modes and killing the processor agent in both spawn and "default" mode.
potiuk
force-pushed
the
fix-race-condition-with-killing-processor-mnager
branch
from
b309675 to
fdbcdd2
Compare
ashb
approved these changes
Dec 2, 2021
|
The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease. |
github-actions
bot
added
the
full tests needed
Member
Author
|
Woohooo! |
potiuk
added a commit
that referenced
this pull request
Dec 11, 2021
As described in detail in #19860, there was a race condition in starting and terminating DagProcessorAgent that caused us a lot of headeaches with flaky test_scheduler_job failures on our CI and after long investigation, it turned out to be a race condition. Not very likely, but possible to happen in production. The race condition involved starting DagProcessorAgent via multiprocessing, where the first action of the agent was changing the process GID to be the same as PID. If the DagProcessorAgent was terminated quickly (on a busy system) before the process could change the GID, the `reap_process_group` that was supposed to kill the whole group, was failing and the DagProcessorAgent remained running. This problem revealed a wrong behaviour of Airflow in some edge conditions when 'spawn' mode was used for starting the DAG processor Details are described in #19934, but this problem will have to be solved differently (avoiding ORM reinitialization during DAG processor starting). This change also moves the tests for `spawn` method out from test_scheduler_job.py (it was a remnant of old Airlfow and it did not really test what it was supposed to test). Instead tests were added for different spawn modes and killing the processor agent in both spawn and "default" mode. (cherry picked from commit 5254843)
38 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in detail in #19860, there was a race condition in
starting and terminating DagProcessorAgent that caused us a lot
of headeaches with flaky test_scheduler_job failures on our CI
and after long investigation, it turned out to be a race
condition. Not very likely, but possible to happen in production.
The race condition involved starting DagProcessorAgent via
multiprocessing, where the first action of the agent was changing
the process GID to be the same as PID. If the DagProcessorAgent
was terminated quickly (on a busy system) before the process
could change the GID, the
reap_process_groupthat was supposedto kill the whole group, was failing and the DagProcessorAgent
remained running.
This problem revealed a wrong behaviour of Airflow in some edge
conditions when 'spawn' mode was used for starting the DAG processor
Details are described in #19934, but this problem will have to be
solved differently (avoiding ORM reinitialization during DAG
processor starting).
This change also moves the tests for
spawnmethod out fromtest_scheduler_job.py (it was a remnant of old Airlfow and it
did not really test what it was supposed to test). Instead tests
were added for different spawn modes and killing the processor
agent in both spawn and "default" mode.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.