-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Stop using gentle close with heartbeat #8036
Stop using gentle close with heartbeat #8036
Conversation
@@ -134,28 +134,15 @@ static void gentleCloseWithHeartbeat(final Process process, | |||
} | |||
} | |||
|
|||
@VisibleForTesting | |||
static void forceShutdown(final Process process, final Duration lastChanceDuration) { |
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 method was basically a copy of closeProcess()
, but without the logic to actually forcibly shutdown the process (despite the name). So I opted to just remove it and use closeProcess
in its place instead.
@@ -36,6 +36,11 @@ | |||
"title": "Max Records", | |||
"description": "Number of records to emit. If not set, defaults to infinity.", | |||
"type": "integer" | |||
}, | |||
"message_interval": { |
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.
fwiw this field could probably be optional.
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.
great!
@lmossman lmk when you get around tot his bit! |
* use gentle close instead of gentle close with heartbeat when closing source * also lower destination process gentle close duration * add test connectors
Resolves https://github.com/airbytehq/oncall/issues/15
Currently, when a destination fails it causes
close()
to be called on the source and destination. However, the current implementation of this waits until the source process finishes its heartbeats, and then has an extremely long wait time (10 hours) before actually destroying the process, which makes the sync appear to hang during this time.This PR solves the issue by removing the heartbeat check (this wasn't really useful anyway, as heartbeats were only listened to once the process was trying to be closed due to a finished job or error), and lowering the wait time to close the process from 10 hours to 1 minute.
I have tested this out locally using the e2e connectors that this PR adds, and it causes the source process to correctly be promptly closed once after the destination process fails.
Planning to add an acceptance test for this case in a separate PR, as the test will likely take multiple minutes to run and we therefore might not want to add it until we have proper asynchronous testing in place.