lhotari commented on code in PR #23231:
URL: https://github.com/apache/pulsar/pull/23231#discussion_r1738216458
##########
pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java:
##########
@@ -949,6 +949,48 @@ The max allowed delay for delayed delivery (in
milliseconds). If the broker rece
+ " back and unack count reaches to `limit/2`. Using a value of 0,
is disabling unackedMessage-limit"
+ " check and broker doesn't block dispatchers")
private int maxUnackedMessagesPerBroker = 0;
+
+ @FieldContext(
+ category = CATEGORY_POLICIES,
+ doc = "For Key_Shared subscriptions, if messages cannot be
dispatched to consumers due to a slow consumer"
+ + " or a blocked key hash (because of ordering
constraints), the broker will continue reading more"
+ + " messages from the backlog and attempt to dispatch them
to consumers until the number of replay"
+ + " messages reaches the calculated threshold.\n"
+ + "Formula: threshold =
max(keySharedLookAheadMsgInReplayThresholdPerConsumer *"
+ + " connected consumer count,
keySharedLookAheadMsgInReplayThresholdPerSubscription)"
+ + ".\n"
+ + "Setting this value to 0 will disable the limit
calculated per consumer.",
+ dynamic = true
+ )
+ private int keySharedLookAheadMsgInReplayThresholdPerConsumer = 1000;
+
+ @FieldContext(
+ category = CATEGORY_POLICIES,
+ doc = "For Key_Shared subscriptions, if messages cannot be
dispatched to consumers due to a slow consumer"
+ + " or a blocked key hash (because of ordering
constraints), the broker will continue reading more"
+ + " messages from the backlog and attempt to dispatch them
to consumers until the number of replay"
+ + " messages reaches the calculated threshold.\n"
+ + "Formula: threshold =
max(keySharedLookAheadMsgInReplayThresholdPerConsumer *"
+ + " connected consumer count,
keySharedLookAheadMsgInReplayThresholdPerSubscription)"
+ + ".\n"
+ + "This value should be set to a value less than 2 *
managedLedgerMaxUnackedRangesToPersist.\n"
+ + "Setting this value to 0 will disable the limit
calculated per subscription.\n",
+ dynamic = true
+ )
+ private int keySharedLookAheadMsgInReplayThresholdPerSubscription = 10000;
+
+
+ @FieldContext(
+ category = CATEGORY_POLICIES,
+ doc = "For Key_Shared subscriptions, if messages cannot be
dispatched to consumers due to a slow consumer"
+ + " or a blocked key hash (because of ordering
constraints), the broker will continue reading more"
+ + " messages from the backlog and attempt to dispatch them
to consumers until the number of replay"
+ + " messages reaches the calculated threshold.\n"
+ + "This setting controls whether look ahead is enabled
when recently joined consumers are present.",
+ dynamic = true
+ )
+ private boolean keySharedLookAheadEnabledWhenRecentlyJoinedConsumersExist
= false;
Review Comment:
no, that's what exists in the current released versions that it doesn't
"look ahead" when recently joined consumers exist. I guess we need to
experiment whether this could be changed to do the look ahead also in that
case. I was cautious about changing the existing behavior and that's why I
added this flag to control the behavior. We'd need to experiment and analyze
whether the default value could be changed without risks of regressions. I'm
trying to minimize the risks of regressions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]