[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
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: avatica-1.22.0
(was: avatica-1.21.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.22.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.20.7#820007)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
https://issues.apache.org/jira/browse/CALCITE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1341:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.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.21.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.20.1#820001)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
https://issues.apache.org/jira/browse/CALCITE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1341:
-
Fix Version/s: (was: avatica-1.19.0)
avatica-1.20.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.20.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)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
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.18.0)
avatica-1.19.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.19.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)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
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.17.0)
avatica-1.18.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.18.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)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
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)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
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.12.0)
avatica-1.13.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.13.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
(v7.6.3#76005)
