Josh Elser created CALCITE-1341:
-----------------------------------
Summary: Improve mechanism for client/server to unwrap protobuf
RPC message
Key: CALCITE-1341
URL: https://issues.apache.org/jira/browse/CALCITE-1341
Project: Calcite
Issue Type: Improvement
Components: avatica
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Critical
Fix For: avatica-1.9.0
We just ran into a funny bug in PHOENIX-3136 as a fallout of some changes which
relocated Avatica classes.
Because the Avatica RPC classes were also relocated (from
org.apache.calcite.avatica to org.apache.phoenix.org.apache.calcite.avatica),
clients of an older version could no longer communicate with a server of the
newer version (and vice versa). This stems from a decision made where the wire
API included the class name of the Request and Response Java protobuf class in
the message. The server would send back the Response class name with the
relocated name, but the client would not know what that class is (because it
doesn't have the same relocation). In other words, the current protobuf
serialization approach requires that Avatica classes are not shaded and
relocated.
The JSON serialization doesn't have this problem because it uses the
{{JsonSubType}} Jackson annotation to map the Request/Response class to a
logical name (e.g. OpenConnectionResponse to openConnection).
We could do a similar approach for protobuf that the JSON serialization does
(maintain this mapping and guarantee that it is not changed incompatibly).
Long-term, I believe I'd like to see specific Requests dispatched to certain
URLs (instead of all HTTP requests send to {{/}}) and do away with this
additional logic in the serialization layer, but I'm not sure if we have to
re-architect the URL scheme just to fix this issue in the near-term.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
