You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2015/12/02 19:08:11 UTC

[jira] [Resolved] (CALCITE-989) Provide generic server metadata in responses

     [ https://issues.apache.org/jira/browse/CALCITE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Elser resolved CALCITE-989.
--------------------------------
    Resolution: Fixed

Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=3be816f450450e8e43286e6ea208af6e30520146

Lays groundwork for more per-RPC metadata to pass back (a small metrics blob, perhaps), but should be sufficient for clients to make their own load-balancing/routing decisions.

> Provide generic server metadata in responses
> --------------------------------------------
>
>                 Key: CALCITE-989
>                 URL: https://issues.apache.org/jira/browse/CALCITE-989
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.6.0
>
>
> Some follow on from CALCITE-903:
> The assumption in that work was that the common case in running behind a load-balancer is that a given client would continue to be routed back to the same avatica server instance. Sadly, this is not necessarily reality.
> If the only load balancer technology available is only capable of an round-robin algorithm (or similar), we need to provide the information for a client to make a decision to return to the same server upon subsequent requests (e.g. fetching the next page of results).
> Thinking more generally, the server which processed a given request is just general metadata. We could include things like the Avatica version, the "real" JDBC version information, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)