-
As noted in #186, if the routing destination is ambiguous, then one destination will be randomly chosen. This seems bad as the only feedback is a log line that may or may not be actively looked for by users. this multiple-destination behavior may go unnoticed for some time (days/weeks/months/years?) until it causes an impact or is identified as the root cause for an ongoing impact. Treating the message as not-routable would immediately alert users that there is a problem and require that they do the right thing from the start. As there isn't yet precedent for allowing the wrong thing (multiple possible destinations), it doesn't seem like enabling that is the right thing to do. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Maybe this could be make configurable along with some reasonable defaults. |
Beta Was this translation helpful? Give feedback.
-
This is a policy question of whether we should fail fast or try to route anyway. This scenario will only happen if there is a problem with the load balancer component that it hasn't resolved the route to only one host. |
Beta Was this translation helpful? Give feedback.
-
Let me distinguish terms for a moment. Routing happens early where it matches the request parameters and selects a backend group. All destination servers in that group are supposed to be able to handle that request, and it's primarily a Load Balancing decision to pick a single destination server from the list. Given they're all equivalent, routing seemed preferable to failing fast. We chose randomly because it provides a surprisingly good load balancing distribution for minimal effort. Put another way, the cost of failing fast in this scenario is high, the request (and likely all requests) does not get processed. Compared to the cost of continuing, the requests get processed with ok efficiency. Your average site should work fine with the random fallback. If you're looking to improve the performance then you are more likely to find the warning log. |
Beta Was this translation helpful? Give feedback.
Let me distinguish terms for a moment. Routing happens early where it matches the request parameters and selects a backend group. All destination servers in that group are supposed to be able to handle that request, and it's primarily a Load Balancing decision to pick a single destination server from the list. Given they're all equivalent, routing seemed preferable to failing fast. We chose randomly because it provides a surprisingly good load balancing distribution for minimal effort.
Put another way, the cost of failing fast in this scenario is high, the request (and likely all requests) does not get processed. Compared to the cost of continuing, the requests get processed with ok effic…