Cache merged context
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- java
- Ambito
- api, performance
Direzione di ricerca
Inizia da OpenFeatureClient.evaluateFlag() e mergeEvaluationContext(), quindi traccia il modo in cui attualmente vengono combinati i contesti API, transaction, client e invocation. Implementa la propagazione dall’alto verso il basso proposta e il merge memorizzato nella cache dei livelli superiori, quindi aggiorna la documentazione per raccomandare di impostare i contesti prima di creare i client; il lavoro è completo quando le valutazioni eseguono il merge solo del contesto memorizzato nella cache con il contesto invocation.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Currently, the OpenFeatureClient.evaluateFlag() method performs a complete context merge on every flag evaluation by calling mergeEvaluationContext(), which merges all four context levels from scratch: API context (global), Transaction context, Client context, Invocation context (evaluation-specific)
Problem: This bottom-up approach is inefficient because:
- API, transaction, and client contexts change infrequently compared to evaluation frequency
- Each evaluation recreates the same merged context for the stable upper levels
- Unnecessary object allocation and computation occurs on every evaluation
Proposed Solution: Implement a top-down context propagation system:
- API level: When API context changes, propagate to transaction level
- Transaction level: When transaction context changes, propagate to client level
- Client level: When client context changes, create pre-merged context (API + Transaction + Client)
- Evaluation: Only merge the pre-computed context with the invocation context
Benefits:
- Reduces object churn and GC pressure and improves performance in high-evaluation scenarios
- Enables better performance scaling for applications with many flag evaluations
The documentation should recommend setting contexts before creating clients to maximize caching benefits.
- Lingua principale
- Java
- Stelle
- 128
- Fork
- 61
- Merge medio
- 11h 36m
- PR unite (30g)
- 22
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di open-feature/java-sdk
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
open-feature/java-sdk#2019 · 1 commento ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
open-feature/java-sdk#2014 · 1 commento ·
-
Spec v0.9.0 compliance Apertav0.9.0
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
open-feature/java-sdk#1999 ·
-
on setProvider call, shutting down the previous provider should happen before creating the new one Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 50/100
open-feature/java-sdk#1934 · 1 reazione ·
-
multi-provider
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
open-feature/java-sdk#1882 ·
Tutte le issue di open-feature/java-sdk
Issue simili
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
inu-appcenter/memorIN-backend#288 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
frontend maui-pilot pilot-ask question
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Apertaarea/plugin
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
kestra-io/plugin-kestra#190 ·