-
Notifications
You must be signed in to change notification settings - Fork 805
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
Added Executor Interface and TimerTaskExecutorBase with stop() Method and improve context management in TimerQueueProcessor #5920
Added Executor Interface and TimerTaskExecutorBase with stop() Method and improve context management in TimerQueueProcessor #5920
Conversation
…askExecutorBase and calling that in timerqueueprocessor to prevent context leak
Pull Request Test Coverage Report for Build 018ef2bf-3a4f-49cf-8ec7-63574b6bd290Details
💛 - Coveralls |
@@ -87,7 +87,7 @@ func (t *timerActiveTaskExecutor) Execute( | |||
return nil | |||
} | |||
|
|||
ctx, cancel := context.WithTimeout(context.Background(), taskDefaultTimeout) | |||
ctx, cancel := context.WithTimeout(t.ctx, taskDefaultTimeout) |
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 line is unnecessary for TaskTypeDeleteHistoryEvent
case. so maybe create the context within each case below with corresponding timeout value.
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.
Thanks, I have changed this in the new commit.
@@ -178,6 +178,8 @@ func (t *timerQueueProcessor) Stop() { | |||
|
|||
if !t.shard.GetConfig().QueueProcessorEnableGracefulSyncShutdown() { | |||
t.activeQueueProcessor.Stop() | |||
// stop active executor after queue processor | |||
t.activeTaskExecutor.Stop() |
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 are also standbyTaskExecutor
objects created and passed to newTimerQueueStandbyProcessor
in the constructor. We need to stop them as well. Timer queue processor is creating those so it should be responsible of stopping the executors
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.
Thanks, I have added a field accounting for the standbyTaskExecutors and stop then in the end.
What changed?
Added stop() to the Executor interface and created an empty stop() function for future implementations in Executors.
Implemented stop() in TimerTaskExecutorBase.
Added context and cancelFn in TimerTaskExecutorBase struct and replaced context.Background() with internal context to prevent memory leaks.
Called executor.stop() in TimerQueueProcessor to prevent context leaks.
Why?
Currently we are creating new context and pass that to downstream without proper stop signal propagation
How did you test it?
Unit tests
Potential risks
We are calling the stop method at the end of the lifecycle so there won't be any added risks.
Release notes
Documentation Changes