[ https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242459#comment-15242459 ]
stack commented on HBASE-15638: ------------------------------- Thanks [~busbey] Let me look at where we are making direct reference to com.google.protobuf outside of hbase-protocol (Apart from the protos in rest and spark, I think its rpc that is the culprit.... ). Let me see what I can move back. Let me see how far I get. On the uses-relocated-protobuf suggestion, let me see list of items we'd need to disentangle and what would be involved. My first reaction is that profile for some modules might be a little opaque in its workings but let me turn it over as I bang my head here. Thanks. > Shade protobuf > -------------- > > Key: HBASE-15638 > URL: https://issues.apache.org/jira/browse/HBASE-15638 > Project: HBase > Issue Type: Bug > Components: Protobufs > Reporter: stack > Attachments: 15638v2.patch, as.far.as.server.patch > > > Shade protobufs so we can move to a different version without breaking the > world. We want to get up on pb3 because it has unsafe methods that allow us > save on copies; it also has some means of dealing with BBs so we can pass it > offheap DBBs. We'll probably want to change PB3 to open it up some more too > so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase] > and [~ram_krish]'s offheaping of the readpath work. > This change is mostly straight-forward but there are some tricky bits: > # How to interface with HDFS? It wants its ByteStrings. Here in particular > in FanOutOneBlockAsyncDFSOutputSaslHelper: > {code} > if (payload != null) { > builder.setPayload(ByteString.copyFrom(payload)); > } > {code} > # [~busbey] also points out that we need to take care of endpoints done as > pb. Test at least. > Let me raise this one on the dev list too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)