From 3da4337c37a995fb21087f1d3cf54102e45ba2be Mon Sep 17 00:00:00 2001 From: andythsu Date: Tue, 27 May 2025 18:34:58 -0400 Subject: [PATCH] Update routing-logic.md --- docs/routing-logic.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/routing-logic.md b/docs/routing-logic.md index 1150fff59..42c47b493 100644 --- a/docs/routing-logic.md +++ b/docs/routing-logic.md @@ -3,12 +3,12 @@ ## Overview Trino Gateway checks incoming requests to see if they're related to previous -ones it handled. If they are, then Trino Gateway sends them to the same backend -that dealt with the earlier requests. +ones it handled. If they are, then Trino Gateway sends them to the same +Trino cluster that dealt with the earlier requests. If it is a new request, the Trino Gateway refers to [Routing rules](routing-rules.md) -to decide which group of backends, called a 'Routing Group,' should handle it. -It then picks a backend from that Routing Group to handle the request using +to decide which group of clusters, called a 'Routing Group,' should handle it. +It then picks a cluster from that Routing Group to handle the request using either an adaptive or round-robin strategy. ![Request Routing Flow](assets/gateway-routing-flow.svg) @@ -16,26 +16,26 @@ either an adaptive or round-robin strategy. ## Sticky routing A request related to an ongoing process, or to state maintained on a single -backend cluster, must be routed to that backend for proper handling. Two +Trino cluster, must be routed to that cluster for proper handling. Two mechanisms for identifying related requests are currently implemented. By default, only routing based on query identifier is enabled. ### Routing based on query identifier (default) When a query is initiated through the Trino Gateway, the query id will be -extracted from the response and mapped to the backend that provided the +extracted from the response and mapped to the cluster that provided the response. Any subsequent request containing that query id will be forwarded -to that backend. For example, to retrieve query results, the trino client +to that cluster. For example, to retrieve query results, the Trino client polls a URI of the form `v1/statement/executing/queryid/nonce/counter`. The Trino Gateway will extract the queryid from this URI. ### Routing based on cookies -OAuth2 authentication requires that the same backend is used for each step of +OAuth2 authentication requires that the same cluster is used for each step of the handshake. When `gatewayCookieConfiguration.enabled` is set to true, a cookie will be added to requests made to paths beginning with `/oauth2` unless they already have -a cookie present, which is used to route further `/oauth2/*` requests to the correct backend. +a cookie present, which is used to route further `/oauth2/*` requests to the correct cluster. Cookies are not added to requests to `v1/*` and other Trino endpoints. Trino Gateway signs its cookies to ensure that they are not tampered with. You @@ -54,7 +54,7 @@ the paths used to define the OAuth handshake may be modified. `routingPaths`: If the request URI starts with a path in this list, then * If no cookie is present, add a routing cookie -* If a cookie is present, route the request to the backend defined by that cookie +* If a cookie is present, route the request to the cluster defined by that cookie `deletePaths`: If the request URI starts with a path in this list, return a response that instructs the client to delete the cookie.