oneby-wang opened a new pull request, #25852: URL: https://github.com/apache/pulsar/pull/25852
Fixes apache/pulsar#25815 This test has already been fixed by [apache/pulsar@55e6022](https://github.com/apache/pulsar/commit/55e6022f2a12cd775f90e09a8756feb02dd2b1b0). This PR refines the test implementation. ### Motivation `ResendRequestTest.testSharedSingleAckedPartitionedTopic` is flaky because it assumes that both consumers on a shared subscription will receive at least one message. The test used blocking `receive()` calls for both consumers before entering the receive loop. If the first consumer receives messages but the second consumer does not, the test can block until the TestNG timeout. This can happen even when producer batching is disabled. `enableBatching=false` only means the producer will not combine multiple user messages into one batch message or one batch entry. The broker dispatcher can still read multiple entries from the managed ledger, select one available consumer, and dispatch multiple entries to that consumer consecutively. This is dispatcher-side batch dispatch, not producer batching. The relevant broker path is `PersistentDispatcherMultipleConsumers.trySendMessagesToConsumers`: https://github.com/apache/pulsar/blob/953bf34a26d647b4640f3087cc27f54f090c878a/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java#L826-L849 `getMaxEntriesInThisBatch` chooses how many entries to send to the selected consumer based on the available permits and `dispatcherMaxRoundRobinBatchSize`. The default `dispatcherMaxRoundRobinBatchSize` is `20`. In this test, each partition only has 3 or 4 messages and each consumer has `receiverQueueSize(7)`, so one consumer can have enough permits to receive all entries for a partition. Because this is a shared subscription, Pulsar does not guarantee that every consumer receives at least one message. The test now produces all messages before creating the shared consumers and subscribes the consumers from `SubscriptionInitialPosition.Earliest`. This intentionally lets the messages accumulate in the partition backlog before dispatch starts, which makes the flaky scenario easier to reproduce: when the consumers subscribe, the broker can read multiple pending entries and dispatch them to the first available shared consumer according to its permits. ### Modifications - Produce messages before creating the consumers and subscribe from `Earliest`, making the original flaky condition easier to reproduce. - Replace the initial blocking `receive()` calls with timed receive loops. ### Verifying this change - [x] Make sure that the change passes the CI checks. ### Does this pull request potentially affect one of the following parts: - [ ] Dependencies (add or upgrade a dependency) - [ ] The public API - [ ] The schema - [ ] The default values of configurations - [ ] The threading model - [ ] The binary protocol - [ ] The REST endpoints - [ ] The admin CLI options - [ ] The metrics - [ ] Anything that affects deployment -- 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]
