Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-989

Provide generic server metadata in responses

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: avatica
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        elserj Josh Elser added a comment -

        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?

        Show
        elserj Josh Elser added a comment - 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?
        Hide
        elserj Josh Elser added a comment -

        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.

        Show
        elserj Josh Elser added a comment - 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.
        Hide
        elserj Josh Elser added a comment -

        Reopening to fix the Coverity issues.

        Show
        elserj Josh Elser added a comment - Reopening to fix the Coverity issues.
        Show
        elserj Josh Elser added a comment - Fixed some static analysis finds in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=d259cad23d396cef213f6e773f2e22e205f4230c
        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.6.0 (2016-01-22).

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.6.0 (2016-01-22).

          People

          • Assignee:
            elserj Josh Elser
            Reporter:
            elserj Josh Elser
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development