[PHOENIX-3136] Relocation of Avatica classes breaks compatibilty between older version of thin-client/PQS

• Type: Bug
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Fix Version/s: 4.8.0
• Assignee: Josh Elser
• Reporter: Josh Elser
• Created: 02/Aug/16 15:19
• Updated: 18/Dec/17 04:58
• Resolved: 02/Aug/16 23:26

Description

It was recently brought to my attention by Holman Lan 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.

Issue Links

• is broken by: PHOENIX-2535 Create shaded clients (thin + thick)
• is related to: CALCITE-1341 Improve mechanism for client/server to unwrap protobuf RPC message
• relates to: PHOENIX-4466 java.lang.RuntimeException: response code 500 - Executing a spark job to connect to phoenix query server and load data