[
https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236280#comment-16236280
]
Lars Hofhansl commented on HBASE-12091:
---------------------------------------
I wouldn't mind some comments :)
To make it more reliable we do this in (in order of more complexity):
# Change sink to throw a newly created TNFE back to the source when that
condition is detected. That way sink and source control the exact message.
Still needs simple parsing as IPCUtil prepends the classname and appends the
stack trace to the message, but the message would be controlled inside of the
replication logic.
# Invent a new mechanism to pass exception conditions back to the source. That
looks to be pretty involved.
Or we leave it this way and rely on the tests to trap if somebody messes with
the exception messages.
> 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
> Priority: Major
> Fix For: 1.4.0
>
> Attachments: 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.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)
