[Broker] Fix messageDedup delete inactive producer name - #12493
Merged
congbobo184 merged 3 commits intoOct 27, 2021
Merged
Conversation
Contributor
|
@congbobo184:Thanks for your contribution. For this PR, do we need to update docs? |
Contributor
|
@congbobo184:Thanks for providing doc info! |
codelipenghui
approved these changes
Oct 26, 2021
merlimat
reviewed
Oct 26, 2021
| * Topic will call this method whenever a producer connects. | ||
| */ | ||
| public synchronized void producerAdded(String producerName) { | ||
| public void producerAdded(String producerName) { |
Contributor
There was a problem hiding this comment.
We shouldn't remove the synchronized here because it's used also to make operations atomic with other methods. eg. purgeInactiveProducers()
zeo1995
pushed a commit
to zeo1995/pulsar
that referenced
this pull request
Oct 27, 2021
* up/master: fix delete authentication policies when delete topic. (apache#12215) [Broker] Fix messageDedup delete inactive producer name (apache#12493) Fixed getting children of parent nodes in LocalMemoryMetadataStore (apache#12491) Update Producer stats on producer close() (apache#12500) docs(cli):add restart command in pulsar-daemon (apache#12373) Add the pulsar java property memory allocator doc (apache#12481) [Doc]Update ci-documentbot.yml (apache#12480)
merlimat
pushed a commit
that referenced
this pull request
Oct 30, 2021
Now, remove inactive producerName in MessageDeduplication when producer close. But the producer has been closed before topic unload, this producerName will not be remove if producer don't connect broker with the same producerName. When topic recover `MessageDeduplication`, we should put every producerName into inactive producerNameMap. When producer with the same name, we will remove it from the inactive map, if this producerName can not connect within brokerDeduplicationProducerInactivityTimeoutMinutes, we can remove it.
1 task
eolivelli
pushed a commit
to eolivelli/pulsar
that referenced
this pull request
Nov 29, 2021
## Issue Now, remove inactive producerName in MessageDeduplication when producer close. But the producer has been closed before topic unload, this producerName will not be remove if producer don't connect broker with the same producerName. ## implement When topic recover `MessageDeduplication`, we should put every producerName into inactive producerNameMap. When producer with the same name, we will remove it from the inactive map, if this producerName can not connect within brokerDeduplicationProducerInactivityTimeoutMinutes, we can remove it.
lhotari
pushed a commit
that referenced
this pull request
Dec 9, 2021
## Issue Now, remove inactive producerName in MessageDeduplication when producer close. But the producer has been closed before topic unload, this producerName will not be remove if producer don't connect broker with the same producerName. ## implement When topic recover `MessageDeduplication`, we should put every producerName into inactive producerNameMap. When producer with the same name, we will remove it from the inactive map, if this producerName can not connect within brokerDeduplicationProducerInactivityTimeoutMinutes, we can remove it. (cherry picked from commit 928924b)
lhotari
pushed a commit
to datastax/pulsar
that referenced
this pull request
Dec 10, 2021
Now, remove inactive producerName in MessageDeduplication when producer close. But the producer has been closed before topic unload, this producerName will not be remove if producer don't connect broker with the same producerName. When topic recover `MessageDeduplication`, we should put every producerName into inactive producerNameMap. When producer with the same name, we will remove it from the inactive map, if this producerName can not connect within brokerDeduplicationProducerInactivityTimeoutMinutes, we can remove it. (cherry picked from commit 04e8d7e)
Jason918
pushed a commit
that referenced
this pull request
Jul 27, 2022
Now, remove inactive producerName in MessageDeduplication when producer close. But the producer has been closed before topic unload, this producerName will not be remove if producer don't connect broker with the same producerName. When topic recover `MessageDeduplication`, we should put every producerName into inactive producerNameMap. When producer with the same name, we will remove it from the inactive map, if this producerName can not connect within brokerDeduplicationProducerInactivityTimeoutMinutes, we can remove it. (cherry picked from commit 928924b)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
fix #12478
Implement
when message deup recover, put producerName into inactiveProduceName map, if producer connect to, it will be removed from inactiveProduceName map
Verifying this change
Add the tests for it
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes
Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (yes)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)