MINOR: changed the test testShareFetchRequestSuccessfulSharingBetweenMultipleConsumers to remove ambiguity
The test testShareFetchRequestSuccessfulSharingBetweenMultipleConsumers was recently found to be flaky. Making the following small change that could potentially resolve the issue. Earlier, 1000 records were being produced and then 3 consecutive share fetch requests were being sent. At the end, assertions were done to make sure each share consumer receives some records, and that none of them consume the same record. Since the motive for the test is to see if multiple consumers can share the same subscription and not consume the same record, a better way would be to produce a record, consume that and repeat it 3 times with the 3 consumers. This ensures that every consumer consume a record, and a previously consume record is not consumed again by the subsequent share fetches.
The test testShareFetchRequestSuccessfulSharingBetweenMultipleConsumers was recently found to be flaky. Making the following small change that could potentially resolve the issue. Earlier, 1000 records were being produced and then 3 consecutive share fetch requests were being sent. At the end, assertions were done to make sure each share consumer receives some records, and that none of them consume the same record. Since the motive for the test is to see if multiple consumers can share the same subscription and not consume the same record, a better way would be to produce a record, consume that and repeat it 3 times with the 3 consumers. This ensures that every consumer consume a record, and a previously consume record is not consumed again by the subsequent share fetches.
@chirag-wadhwa5 but sharing is now happening concurrently now. Isn't that we were testing as well in the test?
Yes, but we do have many other tests for concurrent fetches in ShareConsumerTest. This test, as the name suggest, only checks for multiple share consumers are able to share the same subscription, without consuming the same record multiple times.
Seems good, after addressing @AndrewJSchofield's comments.