Allow consumption of Change Feed as a in-memory push model

Is your feature request related to a problem? Please describe. We’re using ChangeFeedProcessor to update in-memory caches. When an instance of the application dies, a new one takes its place (either via rolling upgrade or failures) and the CFP lease is orphaned (requiring cleanup, sooner or later).

Describe the solution you’d like Allow us to bypass the need for a lease container to read from the change feed. One solution might be to make ChangeFeedProcessorBuilder.WithInMemoryLeaseContainer() public with a way of specifying whether to start from the beginning or end of the change feed. We are able to take snapshots and would just read from the end when starting the application.

Describe alternatives you’ve considered Keep using the existing model and clean up CFP lease containers that haven’t moved (cont. token not brought up to level within n time) - this is less than ideal when the in-memory lease container seems to do exactly what we need, without requiring any cleanup in Cosmos.

Request sprung from discussions in #831.

[ealsur]

@liquidsnk In-memory push scenarios are better served by the Change Feed pull model. Because In-memory has really no benefits (no load balancing nor distribution) over the Pull model. Pull gives more control on the frequency and even lets you store the state if you desire so (also in a controlled fashion, since you can store the continuation token anywhere you want). It is also easier if you are using it in a background process (for example, a Background Host in an ASP.NET app).

Please do describe your scenario so we can see why you’d need In-memory with push?

[ealsur]

The problem is that CFP adds a lot of threads/Tasks in the background for this simple scenario. It would start one parallel set of Tasks for each partition, where each set contains a Task to renew the in-memory leases, a Task to read the changes, and a Task to do cross partition synchronization. It’s just a lot of things that won’t yield any benefit and will potentially add overhead.

With the pull model you can have your Background host periodically just call ReadNextAsync on the FeedIterator. From the lines of code perspective I believe they are pretty similar, both would need a setup (configuring and starting the CFP vs creating the FeedIterator), and consuming it (create a handler or call ReadNextAsync and handle the changes). So you end up coding more or less the same amount and one does not generate the Task overhead.