[fix][flaky-test]Fix PersistentSubscriptionMessageDispatchStreamingDispatcherThrottlingTest.testMultiLevelDispatch

[HQebupt]

Motivation

Fixed #17225

Modifications

• Asynchronously produce messages, but it used to send message synchronously in line:468-471
• I found the failure it is due to dataProvider. I split the subscriptions into two separate data provider.

pulsar/pulsar-broker/src/test/java/org/apache/pulsar/client/api/SubscriptionMessageDispatchThrottlingTest.java

Lines 467 to 479 in 0517423

	long start = System.currentTimeMillis();
	// Asynchronously produce messages
	for (int i = 0; i < numProducedMessages; i++) {
	producer.send(new byte[expectRate / 10]);
	}
	latch.await();
	Assert.assertEquals(totalReceived.get(), numProducedMessages, 10);
	long end = System.currentTimeMillis();
	log.info("-- end - start: {} ", end - start);
	// first 10 messages, which equals receiverQueueSize, will not wait.
	Assert.assertTrue((end - start) >= 2500);
	Assert.assertTrue((end - start) <= 8000);

Verifying this change

• Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.

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: (no)
• The rest endpoints: (no)
• The admin cli options: (no)
• Anything that affects deployment: (no)

Documentation

Check the box below and label this PR (if you have committer privilege).

Need to update docs?

• doc-not-needed

Matching PR in forked repository

PR in forked repository: HQebupt#2

[mattisonchao]

I think we can't remove this line because we have to use it to verify the rate limiter.
Could you get the actual number here? Maybe 2000 is better or not?

[HQebupt]

I agree with you. The longer the time, the more accurate the rate.

[MarvinCai]

can you help explain this new assert? before each message size is rate/10 and we send 30 message, so should take at least 3 second to receive all, but I don't quite understand what this new assert is trying to prove?

[HQebupt]

The test case is correct. And I found the failure is due to dataProvider. I update the PR. PTAL.

[congbobo184]

Why is this assertion so certain, it may cause the test to become more unstable

[HQebupt]

It make sense.