StandByFeedIterator breath first #1121
Conversation
|
Is breadth ask for even a single request response or it for multiple iterations? |
|
Not sure I understand the question. The current model will stay on the same Partition until that partition has no more changes (304). The requested change will move to the next Partition on each request. So in the case of Partitions A, B, and C, where A has 100 changes, B has 50, and C has 50, on the current model we would (with a MaxItemCount of 10):
The problem is that, if while we are reading A, more changes keep pouring over A, we will never move to other Partitions and the changes happening on them will keep lagging behind. With the PR change, we will continuously circle through Partitions on each ReadNextAsync to get 1 set of changes from each Partition, so on the same scenario:
And back to 1. It's the same number of reads to get all changes, just breath first. And if new changes keep pouring over partition A, we won't lock on partition A and let B and C stale. |
|
Assuming compute is okey with it as default behavior. |
| @@ -62,6 +62,9 @@ public override async Task<ResponseMessage> ReadNextAsync(CancellationToken canc | |||
| do | |||
| { | |||
| (currentKeyRangeId, response) = await this.ReadNextInternalAsync(cancellationToken); | |||
| // Read only one range at a time - Breath first | |||
There was a problem hiding this comment.
and nit: breadth with a 'd'
| /// </summary> | ||
| [TestMethod] | ||
| [Timeout(30000)] | ||
| public async Task StandByFeedIterator_BreathFirst() |
There was a problem hiding this comment.
nit: it's breadth, with a 'd'
Pull Request Template
Description
Currently the StandByFeedIterator will only move to the next partition if the current one has no more changes.
In scenarios where all partitions are receiving constant changes, changes from other partitions might get delayed.
With this change, the StandByFeedIterator will move to the next range upon receiving a Change Feed response, so the next
ReadNextAsyncwill read from the next range.Type of change
Please delete options that are not relevant.
Closing issues
This PR closes #1117