[jira] [Commented] (PHOENIX-6144) Phoenix client coexistence with other hadoop components in the same JVM

["Istvan Toth (Jira)" <ji...@apache.org>]

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

Istvan Toth commented on PHOENIX-6144:
--------------------------------------

We often see similar issues with the connectors, which are often fragile, with minor classpath changes or even classpath ordering changes cause conflicts and failures.

> 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
>            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)