[CALCITE-1341] Improve mechanism for client/server to unwrap protobuf RPC message

• Type: Improvement
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Component/s: avatica
• Assignee: Unassigned
• Reporter: Josh Elser
• Created: 02/Aug/16 18:54
• Updated: 28/Feb/24 06:03

Description

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.

Issue Links

• relates to: PHOENIX-3136 Relocation of Avatica classes breaks compatibilty between older version of thin-client/PQS