[
https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244903#comment-16244903
]
Andrew Purtell commented on HBASE-12091:
----------------------------------------
Misplaced comment:
{code}
diff --git a/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
b/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
index cc9fc57c05..6d3074ee43 100644
--- a/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
+++ b/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
@@ -1200,6 +1200,10 @@ public final class HConstants {
public static final String REPLICATION_SOURCE_MAXTHREADS_KEY =
"hbase.replication.source.maxthreads";
+ /** Maximum number of threads used by the replication source for shipping
edits to the sinks */
+ public static final String REPLICATION_DROP_ON_DELETED_TABLE_KEY =
+ "hbase.replication.drop.on.deleted.table";
+
public static final int REPLICATION_SOURCE_MAXTHREADS_DEFAULT = 10;
{code}
This change will cause us to no longer unwrap the remote exception, which is
intended, and that's fine because this method is only called from one place, in
HBaseInterClusterReplicationEndpoint:
{code}
diff --git
a/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
b/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
index dbf7b5e386..af9690a659 100644
---
a/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
+++
b/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java
@@ -69,7 +69,7 @@ public class ReplicationProtbufUtil {
try {
admin.replicateWALEntry(controller, p.getFirst());
} catch
(org.apache.hadoop.hbase.shaded.com.google.protobuf.ServiceException e) {
- throw ProtobufUtil.handleRemoteException(e);
+ throw ProtobufUtil.getServiceException(e);
}
}
{code}
Maybe mention that in the javadoc just to be clear.
I don't like the parsing by regex but I understand why it has to be done.
TableNotFoundException, like all HBase IO exceptions should, is subclassed from
HBaseIOException. What about enhancing HBaseIOException and its serializations
to always carry a TableName, since an HBase IO exception will always involve a
specific table one way or another? Older remotes won't send the extra field,
which is fine, and is handled by protobuf, and in that case you'd fall back to
extracting the tablename from the message. Eventually, that fallback could be
retired. Is there something that prevents this?
> Optionally ignore edits for dropped tables for replication.
> -----------------------------------------------------------
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt,
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt,
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and
> the sink, but the source still has outstanding edits that now it could not
> get rid of. Now all replication is backed up behind these unreplicatable
> edits.
> We should have an option to ignore edits for tables dropped at the source.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
