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

Francis Chuang updated CALCITE-1341:
------------------------------------
    Fix Version/s:     (was: avatica-1.16.0)
                   avatica-1.17.0

> 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.17.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
(v8.3.4#803005)

Reply via email to