-
Notifications
You must be signed in to change notification settings - Fork 141
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
fix jdc sigterm signalling issue #1321
fix jdc sigterm signalling issue #1321
Conversation
Bencher Report
🚨 1 Alert
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1321 +/- ##
==========================================
+ Coverage 16.90% 19.11% +2.21%
==========================================
Files 164 166 +2
Lines 10956 11047 +91
==========================================
+ Hits 1852 2112 +260
+ Misses 9104 8935 -169
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
3aa0262
to
6bb7eb0
Compare
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.
Please explain in the commit what is the ACTUAL fix. What are you doing in order to fix the issue.
6bb7eb0
to
65512c1
Compare
65512c1
to
a3efa46
Compare
tACK I found a typo, but overall LGTM |
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.
Looking good overall. Added a few nits.
Regarding this commit 6a95deb could you please explain why it is added? the title says "move task_status block inside the select macro" but it is not clear why the task_status
was moved. maybe add that in the commit body.
a0ffe75 could have a better title, maybe "Fix typo", or you could just fix it up to the second commit(a3efa46).
a0ffe75
to
0352e78
Compare
@jbesraa I have incorporated your suggestions and updated the commit history to a single commit since the changes are closely related. |
0352e78
to
a9fb6f4
Compare
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.
We tested this locally and it seems that the ghost processes are gone! so this is good to go
0e02c9f
to
b1e6780
Compare
It changes the structuring of the start method, to avoid its blocking nature in case of disconnection from the upstream. Currently, when we are sending the termination signal, during the stance of disconnection from upstream, due of blocking nature of initialize_jd it halts the main thread runtime from executing select block, which listens for any termination signal and channel responses. -Modifications 1. Addition of new shutdown field, which can be used later in integration test to terminate the instances 2. Change argument type for methods initialize_jd and initialize_jd_solo, to make them movable. 3. Spawning of blocking process as a separate task
b1e6780
to
6d1632b
Compare
}, | ||
_ = self.shutdown.notified().fuse() => { | ||
info!("Shutting down gracefully..."); | ||
std::process::exit(0); |
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 should not panic, otherwise it will make tests exist fully. Maybe change to break;
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.
I had this in mind while making the change. I might have mentioned before that this could lead to a complete process exit. Ideally, we should consider breaking out of the outer loop instead.
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.
yea. break
should be enough IMO as we are already in the outer loop
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 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.
Cooll... I will raise one asap
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.
@@ -347,6 +367,10 @@ impl JobDeclaratorClient { | |||
) | |||
.await; | |||
} | |||
|
|||
pub fn shutdown(&self) -> Arc<Notify> { |
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.
After trying this locally, I think two changes need to be done:
- this funciton should not return anything. it should perform the shutdown.
- a unit test to cover this function should be added. If this is working as expected, this unit test should pass:
#[cfg(test)]
mod tests {
use ext_config::{Config, File, FileFormat};
use crate::*;
#[test]
fn test_shutdown() {
let config_path = "config-examples/jdc-config-hosted-example.toml";
let config: ProxyConfig = match Config::builder()
.add_source(File::new(config_path, FileFormat::Toml))
.build()
{
Ok(settings) => match settings.try_deserialize::<ProxyConfig>() {
Ok(c) => c,
Err(e) => {
dbg!(&e);
return;
}
},
Err(e) => {
dbg!(&e);
return;
}
};
let jdc = JobDeclaratorClient::new(config.clone());
let cloned = jdc.clone();
tokio::spawn(async move {
cloned.start().await;
});
jdc.shutdown();
let ip = config.downstream_address.clone();
let port = config.downstream_port;
let jdc_addr = format!("{}:{}", ip, port);
assert!(std::net::TcpListener::bind(jdc_addr).is_ok());
}
}
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.
I added a return type to provide a shutdown handle to the user or, in the case of integration tests, to enable more efficient use of signaling in the future—not just for shutdown scenarios. With this kind of external signaling, we can achieve much more. Therefore, I felt it made sense to pass the handle to the end-user. Let me know your thoughts on this!
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.
What other scenarios could arise? if they exist then a new function should be added.
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 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.
What other scenarios could arise? if they exist then a new function should be added.
Not entirely sure now... But if we ever want to do some channel control...we can achieve that with this signalling mechanisms that we now have in place...
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.
the shutdown
signal is only notified
here https://github.com/stratum-mining/stratum/pull/1321/files/6d1632b2eaca205f4b0e964a7a8d1d4c0b2c5d3a#diff-b344c0ca590735a830cbfb638690b53af5889deeef68717d4586b5da8af62479R171, which is very correct. but it also mean that anyone who is using the shutdown object, can only perform shutdown action. which is also correct, we don't want the same signal to perform different actions.
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.
closes: #1266
Description
This PR introduces several key changes to the
JobDeclaratorClient
implementation to enhance its functionality, improve shutdown handling, and resolve blocking issues during task execution:Use of
tokio::spawn
for Task Initializationinitialize_jd
andinitialize_jd_as_solo_miner
methods are now executed usingtokio::spawn
.Refactored Method Signatures
initialize_jd
andinitialize_jd_as_solo_miner
to acceptProxyConfig
as a parameter instead of relying on&self
.self
from being moved into the spawned tasks and allows for proper cloning and reuse within the async context.Graceful Shutdown Mechanism
tokio::sync::Notify
instance as part ofJobDeclaratorClient
struct to handle shutdown signals. Which now gives power to struct initializer to shutdown process directly.ctrl_c
signal handling with a task that listens for the signal and triggers the shutdown notifier.Simplified Interrupt Signal Handling
ctrl_c
interrupt futures within the select loop.