Skip to content
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][broker] Return if AbstractDispatcherSingleActiveConsumer closed #19934

Merged
merged 3 commits into from
Apr 6, 2023

Conversation

AnonHxy
Copy link
Contributor

@AnonHxy AnonHxy commented Mar 27, 2023

Motivation

We should disconect the consumer and return if AbstractDispatcherSingleActiveConsumer is closed

Modifications

Return after consumer disconnect

Verifying this change

  • Make sure that the change passes the CI checks.

Documentation

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

Matching PR in forked repository

PR in forked repository: AnonHxy#33

@Technoboy- Technoboy- closed this Mar 30, 2023
@Technoboy- Technoboy- reopened this Mar 30, 2023
Copy link
Contributor

@poorbarcode poorbarcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw that NonPersistentStickyKeyDispatcherMultipleConsumers and PersistentStickyKeyDispatcherMultipleConsumers also have the same problem, so we can fix them together?

public synchronized void addConsumer(Consumer consumer) throws BrokerServiceException {
super.addConsumer(consumer);
try {
selector.addConsumer(consumer);
} catch (BrokerServiceException e) {
consumerSet.removeAll(consumer);
consumerList.remove(consumer);
throw e;
}
}

Like the line 89 above, it should not be executed.

And could you write a test for these cases?

@AnonHxy
Copy link
Contributor Author

AnonHxy commented Mar 30, 2023

PersistentStickyKeyDispatcherMultipleConsumers

Good catch @poorbarcode , PTAL again

@codecov-commenter
Copy link

Codecov Report

Merging #19934 (189b1e3) into master (1e44ba1) will increase coverage by 48.44%.
The diff coverage is 85.55%.

Impacted file tree graph

@@              Coverage Diff              @@
##             master   #19934       +/-   ##
=============================================
+ Coverage     24.42%   72.87%   +48.44%     
- Complexity      291    31615    +31324     
=============================================
  Files          1603     1861      +258     
  Lines        124343   137366    +13023     
  Branches      13571    15117     +1546     
=============================================
+ Hits          30369   100101    +69732     
+ Misses        89490    29323    -60167     
- Partials       4484     7942     +3458     
Flag Coverage Δ
inttests 24.34% <18.88%> (-0.08%) ⬇️
systests 25.07% <18.88%> (?)
unittests 72.15% <85.55%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...extensions/reporter/TopBundleLoadDataReporter.java 88.88% <ø> (+88.88%) ⬆️
...tent/NonPersistentDispatcherMultipleConsumers.java 71.60% <ø> (+71.60%) ⬆️
...dbalance/extensions/scheduler/TransferShedder.java 81.43% <50.00%> (+81.43%) ⬆️
...ar/metadata/coordination/impl/LockManagerImpl.java 89.47% <71.42%> (+31.57%) ⬆️
...metadata/coordination/impl/LeaderElectionImpl.java 77.56% <75.00%> (+24.66%) ⬆️
...java/org/apache/pulsar/common/util/FutureUtil.java 80.55% <76.92%> (+50.02%) ⬆️
...ker/loadbalance/extensions/models/TopKBundles.java 90.78% <87.17%> (+90.78%) ⬆️
...org/apache/pulsar/broker/ServiceConfiguration.java 99.37% <100.00%> (+1.46%) ⬆️
...nsions/policies/AntiAffinityGroupPolicyHelper.java 90.62% <100.00%> (+90.62%) ⬆️
...ervice/AbstractDispatcherSingleActiveConsumer.java 92.37% <100.00%> (+24.85%) ⬆️
... and 2 more

... and 1568 files with indirect coverage changes

log.warn("[{}] Dispatcher is already closed. Closing consumer {}", name, consumer);
consumer.disconnect();
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super.addConsumer(consumer) already did this check, right? If yes, we should not repeatedly check it.

log.warn("[{}] Dispatcher is already closed. Closing consumer {}", name, consumer);
consumer.disconnect();
return;
}
super.addConsumer(consumer);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super.addConsumer(consumer) already did this check, right? If yes, we should not repeatedly check it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However the super.addConsumer return value is void. The method in subClass will not fast return if super.addConsumer return. @poorbarcode

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any other comments :) @poorbarcode

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Technoboy- What do you think about this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, super.addConsumer(consumer) can't fast return.

Consumer consumer = mock(Consumer.class);
nonpersistentDispatcher.addConsumer(consumer);
verify(consumer, times(1)).disconnect();
assertEquals(0, nonpersistentDispatcher.getConsumers().size());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a verify: this consumer does not exist in the selector?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I will update it later

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find that it's not easy to access the selector, and verify assertEquals(0, nonpersistentDispatcher.getConsumers().size()); is enough. So maybe we needn't change it @poorbarcode

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Consumer consumer = mock(Consumer.class);
persistentDispatcher.addConsumer(consumer);
verify(consumer, times(1)).disconnect();
assertEquals(0, persistentDispatcher.getConsumers().size());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a verify: this consumer does not exist in the selector?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@michaeljmarshall
Copy link
Member

As discussed on the mailing list https://lists.apache.org/thread/w4jzk27qhtosgsz7l9bmhf1t7o9mxjhp, there is no plan to release 2.9.6, so I am going to remove the release/2.9.6 label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants