twitter/finagle

Dtab alternate not chosen over higher-precedence failing service

Open

#653 opened on 2017年10月4日

GitHub で見る
 (3 comments) (0 reactions) (0 assignees)Scala (8,864 stars) (1,435 forks)batch import
help wanted

説明

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.

コントリビューターガイド

技術スタック
scala
領域
backendapi
Issue 種別
bug
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
4
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
3-5 days
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
stale
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
clear
前提条件
Understanding of Finagle's Dtab routingScala basics
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
25
調査方針
Investigate how Finagle's Dtab resolution currently handles service failures. The key files are likely in com.twitter.finagle.loadbalancer and com.twitter.finagle.naming. Look at how the Balancer interface handles failed requests and whether there is existing support for failure based fallback. The issue asks for a failover mechanism when a service returns failures, which may require changes to the Dtab interpreter or load balancer configuration. Consider looking at the 'loadbalancer' package and the 'failFast' or 'retries' configuration options.