twitter/finagle

Dtab alternate not chosen over higher-precedence failing service

Open

#653 aperta il 4 ott 2017

Vedi su GitHub
 (3 commenti) (0 reazioni) (0 assegnatari)Scala (1435 fork)batch import
help wanted

Metriche repository

Star
 (8864 star)
Metriche merge PR
 (Nessuna PR mergiata in 30 g)

Descrizione

Expected behavior

Suppose I have a dtab

  /svc => /$/namer/srv1 | /$/namer/srv2

I would expect that if every request issued to srv1 resulted in a failure, requests would start being sent to srv2 instead.

Actual behavior

So long as srv1 can be bound to an address, it receives all the traffic.

Is there any way to make it so that srv1 failures will result in requests being routed to srv2? I want srv1 to get traffic preferentially, and I don't want to rely solely on a namer's active health checks to control that.

Guida contributor

Direzione di ricerca
Indaga su come la risoluzione Dtab di Finagle gestisce attualmente i guasti del servizio. I file chiave si trovano probabilmente in com.twitter.finagle.loadbalancer e com.twitter.finagle.naming. Esamina come l'interfaccia Balancer gestisce le richieste fallite e se esiste già un supporto per il fallback basato su guasti. Il problema richiede un meccanismo di failover quando un servizio restituisce guasti, il che potrebbe richiedere modifiche all'interprete Dtab o alla configurazione del bilanciatore del carico. Considera di esaminare il pacchetto 'loadbalancer' e le opzioni di configurazione 'failFast' o 'retries'.
Tech stack
scala
Dominio
backendapi
Tipo issue
Bug
DifficoltàQuanto dovrebbe essere impegnativa per un nuovo contributor.
4
Tempo stimatoTempo stimato per completare e verificare uno scope piccolo.
3-5 giorni
Stato attivitàQuanto è probabile che la issue sia ancora attiva e reviewable.
Datata
ChiarezzaQuanto chiaramente la issue descrive problema, scope e risultato atteso.
Chiara
Prerequisiti
Understanding of Finagle's Dtab routingScala basics
Adatta ai principiantiQuanto la issue è adatta a contributor alla prima esperienza.
25