Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[FEATURE REQ] ChangeFeedProcessor event handler fully reactive implementation

Aperta
#50,758 3 commenti 1 reazione 2 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@FabianMeiswinkel ci sta già lavorando.

Dal 14/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, databases

Direzione di ricerca

The request is about the ChangeFeedProcessorBuilder and the event handler it accepts for Azure Cosmos DB change feed processing. Read the builder and the handler interface in the Cosmos Java SDK to see how the consumer is invoked, then decide how a Mono or Flux handler would be scheduled. Done would mean an agreed API design and the threading contract settled by maintainers, not a patch.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Client Cosmos customer-reported feature-request needs-team-attention Service Attention

Is your feature request related to a problem? Please describe.
Current impossibility to handle change feed events based on the ChangeFeedProcessor created by the ChangeFeedProcessorBuilder reactively is quite limmiting.
In case your whole stack is reactive (as is the Quarkus framework in our case) and you are handling large amounts of change feed events which can by inherently parallelized - blocking event Consumer is limiting .
Currently we are forced to subscribe to our internal handler pipelines in a blocking way which itself imposes a lot of additional issues.

Describe the solution you'd like
I propose to either extend the ChangeFeedProcessorBuilder or provide anoher async version of it with the ability to provide handler in a form of a reactive pipeline. Either Mono<?> or FLux<?>.
Having this would allow reactive frameworks to take a full advantage of the reactive stack including retries, parallelizations and threading.
Internally the change feed event handling is reactive, this fact is however masked and made unavailable to the CosmosSDK users.

Describe alternatives you've considered
We have experimented with the fully reactive approach, forcing the CosmosSDK to call our reactive handler pipeline using reflection. This approach is naturally dangerous and may stop working with any furure CosmosSDk update.
However our first performance measurements are very promissing.
In a specific case when you read a batch of 100 events from the change feed and you are able to split them to about 50-60 parallel chunks and process them non-blockingly in parallel - the gain in throughput was about 35%.

Additional context
It is probably crucial for the CosmosSDK to ensure the result of the change feed events batch processing to be emitted on the same Scheduler it was subscribed on - but this is achievable.

Information Checklist

  • Description Added
  • Expected solution specified
Lingua principale
Java
Stelle
2.6k
Fork
2.2k
Merge medio
1g 22h
PR unite (30g)
213

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Azure/azure-sdk-for-java

Tutte le issue di Azure/azure-sdk-for-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.