[fix][broker] WaitForExclusive should fenced when exist Shared producer.

[shibd]

Motivation

In the current implementation, if a Shared Producer is created first, and can be again created successfully a producer of the WaitForExclusive.

It's confuse. Because even if the Shared producer is disconnected, it will not trigger the WaitForExclusive producer to become exclusive.

Modifications

• WaitForExclusive producer should fence when existing Shared producer.

Documentation

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

Matching PR in forked repository

PR in forked repository: shibd#20

[codecov-commenter]

Codecov Report

Merging #18380 (674e7a8) into master (2e878e8) will increase coverage by 5.43%.
The diff coverage is 44.00%.

@@             Coverage Diff              @@
##             master   #18380      +/-   ##
============================================
+ Coverage     40.04%   45.48%   +5.43%     
- Complexity     8625    10809    +2184     
============================================
  Files           687      757      +70     
  Lines         67436    74036    +6600     
  Branches       7221     8116     +895     
============================================
+ Hits          27007    33675    +6668     
+ Misses        37411    36594     -817     
- Partials       3018     3767     +749     

Flag	Coverage Δ
unittests	45.48% <44.00%> (+5.43%)	⬆️

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

Impacted Files	Coverage Δ
.../org/apache/pulsar/broker/admin/AdminResource.java	66.58% <0.00%> (+<0.01%)	⬆️
...apache/pulsar/broker/admin/impl/FunctionsBase.java	0.00% <0.00%> (ø)
...org/apache/pulsar/broker/admin/impl/SinksBase.java	0.00% <0.00%> (ø)
...g/apache/pulsar/broker/admin/impl/SourcesBase.java	0.00% <0.00%> (ø)
...a/org/apache/pulsar/broker/admin/v2/Functions.java	0.00% <0.00%> (ø)
...java/org/apache/pulsar/broker/admin/v2/Worker.java	0.00% <0.00%> (ø)
...org/apache/pulsar/broker/admin/v2/WorkerStats.java	0.00% <0.00%> (ø)
...broker/delayed/InMemoryDelayedDeliveryTracker.java	68.33% <0.00%> (+3.33%)	⬆️
...rg/apache/pulsar/broker/service/AbstractTopic.java	64.67% <0.00%> (-0.05%)	⬇️
...ervice/persistent/MessageRedeliveryController.java	60.97% <ø> (ø)
... and 295 more

[poorbarcode]

No, I don't agree. The user should have a scenario like this:

Users used multiple producers before and need to change to Exclusive now. In this case, if users want to smooth over, users need the coexistence of the producers of both modes Shared(old) and Exclusive(new)

[shibd]

No, I don't agree. The user should have a scenario like this:

Users used multiple producers before and need to change to Exclusive now. In this case, if users want to smooth over, users need the coexistence of the producers of both modes Shared(old) and Exclusive(new)

I think we should keep the Exclusive functional single and should not allow both Shared and WaitForExclusive to appear at the same time. @merlimat Can you take a look at it?

[eolivelli]

I think that a Exclusive producer should fence out all of the existing shared producers.

The point of WaitForExclusive is the you want to take control over the topic, but wait if there is another Exclusive producer connected or enquired as WaitForExclusive.

[shibd]

I think that a Exclusive producer should fence out all of the existing shared producers.

The point of WaitForExclusive is the you want to take control over the topic, but wait if there is another Exclusive producer connected or enquired as WaitForExclusive.

Isn't direct fencing a bit forcible? If the user wants to fence all existing Shared producers, he can use ExclusiveWithFencing mode.

[eolivelli]

I am not sure that we agree on this change.

A WaitForExclusive producer cannot complete by throwing 'Fenced'.
You are Fenced after becoming the owner, but in this case the Producer was never been elected as owner of the topic.

I think that we should behave like Exclusive and ExclusiveWithFencing: if there are Shared producers they must be disconnected and fail

[shibd]

@eolivelli Thanks for your reply.

I think that we should behave like Exclusive and ExclusiveWithFencing: if there are Shared producers they must be disconnected and fail

In fact, Exclusive's current behavior is that when it encounters has shared producer, it will fence itself.

pulsar/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/AbstractTopic.java

Lines 752 to 754 in 5b062f3

	} else if (!producers.isEmpty()) {
	return FutureUtil.failedFuture(new ProducerFencedException("Topic has existing shared producers"));
	} else if (producer.getTopicEpoch().isPresent()

In my opinion, this scenario occurs when the user connects to the wrong topic. We should tell Exclusive/WaitForExclusive producers about the exception of existing shared producers, rather than fence existing shared producers.

[congbobo184]

my point is if the share producer connects first, the WaitForExclusive producer behavior should be like Exclusive. WaitForExclusive is only used if an Exclusive consumer has connected to the topic, if don't have an Exclusive consumer, its behavior doesn't have any difference from the Exclusive consumer.

[github-actions]

The pr had no activity for 30 days, mark with Stale label.