Job moved from inflight queue to comma-joined queue on worker shutdown in RESET_TO_HIGHEST_PRIORITY strategy.
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- java, redis
- Ambito
- backend, distributed-systems
Direzione di ricerca
Inizia da WorkerPoolImpl::getNextQueue() e WorkerPoolImpl::removeInFlight(), quindi esamina fromMultiplePriorityQueues.sha per confrontare la coda usata per il polling con quella usata durante il requeueing dello shutdown. Riproduci lo scenario RESET_TO_HIGHEST_PRIORITY con q1, q2, q3 e q4 e verifica che lo shutdown non lasci job in una chiave Redis non sottoposta a polling, come namespace:queue:q1,q2,q3,q4.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I have noticed that in certain scenarios (immediate worker shutdown), jobs are removed from the inflight queue and then moved to another queue.
Consider the case where I have the following queues: q1, q2, q3, q4.
My workers are meant to process jobs from these queues.
WorkerPoolImpl::getNextQueue() returns a string of "q1,q2,q3,q4" (for RESET_TO_HIGHEST_PRIORITY) and this is stored in curQueue variable.
During pop, the lua script (fromMultiplePriorityQueues.sha) pops from a single queue and returns the job. But when the worker is shutting down, the jobs are removed from the inflight queue and pushed to a queue "q1,q2,q3,q4". resulting in a new key on redis "namespace:queue:q1,q2,q3,q4". This code is in WorkerPoolImpl::removeInFlight.
What is the purpose of storing the jobs in this comma-joined queue? From what I could see, no worker would poll from this queue as the lua script would always pop from the individual queues.
- Lingua principale
- Java
- Stelle
- 629
- Fork
- 132
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 gresrun/jesque
-
Pooled clients leak a connection per call: pipelines and transactions taken from UnifiedJedis are never closedForse già presa @ali-jawad l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
-
Latest jedis SDK support?Forse di nuovo libera @gresrun l’ha presa 295 giorni fa e non c’è nessuna pull request aperta. ApertaDiscussion
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
-
Redis Cluster IssueAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
NoSuchConstructorExceptionAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
Tutte le issue di gresrun/jesque
Issue simili
-
dev/release: verify-release-candidate.sh runs 0 Java tests with Debian's MavenForse già presa @kou l’ha presa oggi. ApertaType: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/arrow-adbc#4947 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
checkstyle/checkstyle#22153 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
-
Documentation Needs Triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
frankframework/frankframework#11908 ·
I maintainer di solito rispondono entro 1 giorno