[
https://issues.apache.org/jira/browse/HBASE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877651#comment-13877651
]
Andrew Purtell commented on HBASE-10322:
----------------------------------------
bq. I'd be +1 on committing this in meantime.
+1 for commit of v5 as is. Thanks for seeing this through Anoop and Ram.
Please add a release note about HConstants.REPLICATION_CODEC_CONF_KEY.
Fix the comment above this change on commit:
{noformat}
diff --git
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
index a612b18..305a76a 100644
--- hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
+++ hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
@@ -1300,7 +1300,7 @@ public class RpcClient {
Codec getCodec() {
// For NO CODEC, "hbase.client.rpc.codec" must be the empty string AND
// "hbase.client.default.rpc.codec" -- because default is to do cell block
encoding.
- String className = conf.get("hbase.client.rpc.codec",
getDefaultCodec(this.conf));
+ String className = conf.get(HConstants.RPC_CODEC_CONF_KEY,
getDefaultCodec(this.conf));
if (className == null || className.length() == 0) return null;
try {
return (Codec)Class.forName(className).newInstance();
{noformat}
bq. Andrew can make the call on whether to wait on test completion before
RC'ing or not.
I'd really like a test if we get one in. Would have to be a LargeTest given it
spins up two clusters. If it proves difficult then we can skip it. Or, if it
flakes during RC testing, we can revert it for 0.98.1. Therefore it makes sense
to me to do it as a follow up issue.
Please also update the replication section of the manual to inform the user
what HConstants.REPLICATION_CODEC_CONF_KEY does. We also need an update of the
section talking about tags that setting HConstants.REPLICATION_CODEC_CONF_KEY
to the tags-aware codec is required to replicate tags from one cluster to
another.
[~stack]: The security coprocessors use operation attributes to ship metadata
to the server. The downside is you have to take care because all cells bundled
in the op will get the same metadata and the server has to rewrite the incoming
cells, but the upside is we don't care about any limitations we might have with
tags on the client. We can make tags "first class" for 1.0. We will have to
look at things like negotiating codecs on the connection at that time.
> Strip tags from KV while sending back to client on reads
> --------------------------------------------------------
>
> Key: HBASE-10322
> URL: https://issues.apache.org/jira/browse/HBASE-10322
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Priority: Blocker
> Fix For: 0.98.0, 0.99.0
>
> Attachments: HBASE-10322.patch, HBASE-10322_V2.patch,
> HBASE-10322_V3.patch, HBASE-10322_V4.patch, HBASE-10322_V5.patch,
> HBASE-10322_codec.patch
>
>
> Right now we have some inconsistency wrt sending back tags on read. We do
> this in scan when using Java client(Codec based cell block encoding). But
> during a Get operation or when a pure PB based Scan comes we are not sending
> back the tags. So any of the below fix we have to do
> 1. Send back tags in missing cases also. But sending back visibility
> expression/ cell ACL is not correct.
> 2. Don't send back tags in any case. This will a problem when a tool like
> ExportTool use the scan to export the table data. We will miss exporting the
> cell visibility/ACL.
> 3. Send back tags based on some condition. It has to be per scan basis.
> Simplest way is pass some kind of attribute in Scan which says whether to
> send back tags or not. But believing some thing what scan specifies might not
> be correct IMO. Then comes the way of checking the user who is doing the
> scan. When a HBase super user doing the scan then only send back tags. So
> when a case comes like Export Tool's the execution should happen from a super
> user.
> So IMO we should go with #3.
> Patch coming soon.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
