Support pluggable workflow caches
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- java
- Ambito
- backend, distributed-systems
Direzione di ricerca
Inizia individuando la cache LRU integrata attuale per i thread dei workflow e verificando come i workflow vi entrano, vi rimangono e ne escono. Definisci il confine della cache collegabile, il comportamento LRU predefinito e il contratto dell’implementazione fornita dall’utente; il lavoro è completato quando è possibile fornire strategie alternative senza modificare il comportamento predefinito esistente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
There are cases where the current integrated LRU cache for workflow threads may not sufficiently capture the optimal strategy for all workloads.
For example, some high-volume workloads allow the cache to fill with workflows that are effectively abandoned because a remote worker completed them without any invalidation signal to clear the defunct task within the current worker. These abandoned workflows add extra eviction overhead for new, unrelated workflows, and the system may sometimes benefit from alternate eviction strategies that differ from the current synchronous LRU algorithm. Examples include augmenting the LRU with a TTL model, or adding an asynchronous/background eviction mechanism.
The proposal is to add a mechanism allowing a pluggable cache that defaults to the current LRU design, allowing SDK end-users to supply their own implementations when desired.
- Lingua principale
- Java
- Stelle
- 434
- Fork
- 252
- Merge medio
- 6g 5h
- PR unite (30g)
- 25
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi 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 temporalio/sdk-java
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
temporalio/sdk-java#2676 · 8 commenti · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
temporalio/sdk-java#1825 ·
I maintainer di solito rispondono entro 1 giorno
-
test server
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
temporalio/sdk-java#3088 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Warn if the SDK tried to send a payload above a specific size - JavaForse già presa @jmaeagle99 l’ha presa 19 giorni fa. Aperta
temporalio/sdk-java#3059 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Allow configurable prefix for MDC keysForse già presa @maciejdudko l’ha presa 19 giorni fa. Apertaenhancement
temporalio/sdk-java#3058 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di temporalio/sdk-java
Issue simili
-
P2 testing
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
area/core kind/bug status/triage team/core-shared
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
checkstyle/checkstyle#21755 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
spring-projects/spring-integration#11495 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno