-
Notifications
You must be signed in to change notification settings - Fork 818
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
Bugfix: deadlock when domain failover #919
Changes from 1 commit
acb5769
5cb965a
0f119d1
dc269a0
530af64
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -143,7 +143,9 @@ func (t *timerQueueProcessorImpl) FailoverDomain(domainID string) { | |
failoverTimerProcessor := newTimerQueueFailoverProcessor(t.shard, t.historyService, domainID, | ||
standbyClusterName, minLevel, maxLevel, t.matchingClient, t.logger) | ||
failoverTimerProcessor.Start() | ||
failoverTimerProcessor.timerQueueProcessorBase.readAndFanoutTimerTasks() | ||
// use a fake timer to trigger db scan | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 'readAndFanoutTimerTasks' is still called from other places and I thought that is the one which could block. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. readAndFanoutTimerTasks will be called by an separate go routine, so we should be fine. |
||
fakeDecisionTimeoutTask := []persistence.Task{&persistence.DecisionTimeoutTask{VisibilityTimestamp: t.shard.GetTimeSource().Now()}} | ||
failoverTimerProcessor.notifyNewTimers(fakeDecisionTimeoutTask) | ||
} | ||
|
||
func (t *timerQueueProcessorImpl) getTimerFiredCount(clusterName string) uint64 { | ||
|
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.
Looks like both before and after callbacks were called within the lock before this change and now they are called outside of the lock. Do we even need 2 separate callbacks?
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 do not really need a 2 type of callbacks, one before one after, i thought providing 2 type of callbacks can be useful