-
Notifications
You must be signed in to change notification settings - Fork 34
Fix shutdown time #188
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 shutdown time #188
Conversation
Codecov Report
@@ Coverage Diff @@
## main #188 +/- ##
==========================================
- Coverage 58.48% 58.38% -0.11%
==========================================
Files 58 58
Lines 3365 3371 +6
==========================================
Hits 1968 1968
- Misses 1268 1274 +6
Partials 129 129
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
@mariomac thanks for adding this PR ... there is a centralized process to exit all threads in FLP ... the code is here: https://github.com/netobserv/flowlogs-pipeline/blob/main/pkg/pipeline/utils/exit.go#L46 can you use the |
cmd/flowlogs-pipeline/main.go
Outdated
| }() | ||
|
|
||
| // Subscribe to signals for terminating the program. | ||
| signal.Notify(stopper, os.Interrupt, syscall.SIGTERM) |
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 has to be integrated to work with exiting all the other threads that exit when SIGINT or SIGTERM are received. See SetupElegantExit() in flowlogs-pipeline/pkg/pipeline/utils/exit.go
|
Thanks for the info, @eranra & @KalmanMeth ! I didn't realized this elegant shutdown mechanism. I adapted the GRPC ingester to work with it and also changed the mechanism itself to use the standard practices in Golang: Instead of a buffered bool channel, I created an unbuffered Also, the common practice when you want to use a channel as a barrier is not to send a message and read it, but close it. When you try to read a closed channel, the read operation will continue. This actually allows to share a single channel that is closed once and will allow the rest of instances to block until it is closed. In this PR, I am still using one single channel for ingester, but in a later PR we can share the same channel for all the instances that want the elegant shutdown. |
eranra
left a comment
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.
Hi @mariomac ... thanks for improving the mechanism ... very nice and clean ;-)
Some nodes, such as the GRPC+Protobuf server, are not very friendly to shutdown signals from Kubernetes, and may take up to 1 minute before Kubernetes eventually kills the pods. This makes undeployments and redeployments to be very slow.
This PR captures the SIGTERM signals and stops the main goroutine when they are received. The pipeline runs in background so it is automatically stopped when the main goroutine ends.