[
https://issues.apache.org/jira/browse/CALCITE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023255#comment-15023255
]
Josh Elser commented on CALCITE-989:
------------------------------------
One concern for a generic "struct" of server metadata-per-response is bloating
the size of each Response. CALCITE-836 has a suggestion to expose some Avatica
server "metadata" (the avatica server's version). It would be confusing to have
RPCs contain this information while having an explicit API for requesting it
(via the DatabaseProperty's).
Perhaps the only good piece of data per Response is data explicitly about that
request/response (and not about the server in general): the server's address
and processing time. Maybe there are others I haven't thought of?
> 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: next
>
>
> 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)
