[
https://issues.apache.org/jira/browse/PHOENIX-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207938#comment-17207938
]
Istvan Toth commented on PHOENIX-6144:
--------------------------------------
This PR introduces a new phoenix-client-byo-hbase artifacts, that combines the
aggressive relocations in PHOENIX-6151 with the provided dependency
declarations from phoenix-server (plus PHOENIX-6176).
One major difference is that we do not mark *protobuf-java* as provided, but
shade/relocate 2.5.0 into the jar, to solve protobuf version clash problems.
> Phoenix client coexistence with other hadoop components in the same JVM
> -----------------------------------------------------------------------
>
> Key: PHOENIX-6144
> URL: https://issues.apache.org/jira/browse/PHOENIX-6144
> Project: Phoenix
> Issue Type: Wish
> Components: core
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
>
> We would like to offer a solution to use phoenix client concurrently with
> other hadoop components in the same VM.
> phoenix-client is not working in this case, because the components with
> relocations in the fat jar clash with the "normal" hadoop components.
> Using the unshaded phoenix-core directly would be a possible solution, but
> this can easily result in version conflicts (in our specific case, protobuf
> 2.5 vs 3.x)
> I could see two ways we could take:
> One is shading everything in phoenix-client outside org.apache.phoenix, so
> that there are guaranteed to be no conflicts. I doubt that this is actually
> feasible, but would love to be proven wrong.
> Another solution would be expanding the existing thirdparty components. We
> could check what HBase does, and make a phoenix-thirdparty version that we
> also use.
> I thought about using the components shaded into phoenix-client directly, but
> I think that we consider those an implementation detail, and don't want to
> commit to maintiaining compatibility, not to mention that they may have
> unexpected (to the user) relocations.
> The current workaround is using PQS+thin client, but this not always optimal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
