More cluster aware MAXLEN option in ADDJOB
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 20/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- c
- Ambito
- distributed-systems
Direzione di ricerca
Inizia tracciando la gestione di ADDJOB e l’attuale controllo locale di MAXLEN nel codice C. Confronta i due approcci proposti a livello di cluster, inclusi i pacchetti ADDJOB, i NACK, le risposte GOTJOB e le lunghezze delle code delle repliche; l’issue sarà completata solo quando sarà stato specificato e implementato un comportamento a livello di cluster deciso e testato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The idea is that while we don't want to run consensus or alike to make sure the queue is a given length, it should have a more global meaning. Example of things we could do:
- Send the MAXLEN count in the ADDJOB cluster packet, and let the receiver discard the packet or NACK if the MAXLEN is reached on the receiver. This way the option is already more cluster aware since the job will be replicated only by instances where the queue length is less than MAXLEN. In turn this means that all the node will eventually reach MAXLEN if the consumers are not fast enough.
- Reply to ADDJOB (GOTJOB) may carry the current length of the queue in the target so that if the sum of our queue length and the replicas is greater than MAXLEN, we don't accept the job.
There is to consider if in the Big Picture this really helps or not. The current behavior is to just check the local queue length. Given Disque automatic federation, if the length was reached in the local node, likely there is no demand or not enough demand for jobs cluster-wide, so it may make sense to have just a local limit. However this issue is here as a placeholder in order to rethink the problem soon or later.
- Lingua principale
- C
- Stelle
- 8.1k
- Fork
- 532
- 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 antirez/disque
-
make nextAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 15/100
-
有编译好的disque吗Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
-
Project status update!Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
Tutte le issue di antirez/disque
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 8 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
native-cpu: -Wreturn-type in skainet_row_threads.c:150 (worker fn has no return)Forse già presa @Doomguy-BFG9000 l’ha presa oggi. Apertagood first issue size:xs skill:native
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
SKaiNET-developers/SKaiNET#1358 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
I/O internal correctness medium priority rt_lib
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno