phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3136) Relocation of Avatica classes breaks compatibilty between older version of thin-client/PQS
Date Wed, 03 Aug 2016 02:45:20 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405213#comment-15405213
] 

Hudson commented on PHOENIX-3136:
---------------------------------

SUCCESS: Integrated in Phoenix-master #1351 (See [https://builds.apache.org/job/Phoenix-master/1351/])
PHOENIX-3136 Do not relocate org.apache.calcite in (elserj: rev 7febdfa881d6a0d41efc289968c8df30953ad39e)
* phoenix-queryserver-client/pom.xml
* phoenix-queryserver/pom.xml


> Relocation of Avatica classes breaks compatibilty between older version of thin-client/PQS
> ------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3136
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3136
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 4.8.0
>
>         Attachments: PHOENIX-3136.001.patch
>
>
> It was recently brought to my attention by [~holman.lan0@gmail.com] that the shading
change will break all previous versions of the thin client from working with the newer PQS
(and vice versa).
> Avatica uses the full class name in the message to identify what protobuf message to
use to deserialize the bytes from the wire. As such, an older thin client would be expecting
these protobuf classes to look like {{org.apache.calcite.avatica.proto.Responses$PrepareResponse}}.
However after PHOENIX-2535, PQS would be sending back {{org.apache.phoenix.shaded.org.apache.calcite.avatica.proto.Responses$PrepareResponse}}.
Both are trying to refer to the same Java class, but we can't disambiguate presently.
> Long term, I think the protocol itself will have to be updated in Avatica to be a little
less brittle in this regard (I did not originally consider the implications that client/server
might *have* the classes, but with a different name than what we had in Avatica).
> Short term, we can undo the relocation of the Avatica classes in the thin-client and
queryserver artifacts. I will be working on this post-haste. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message