[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901624#comment-16901624
]
Geoffrey Jacoby commented on HBASE-22623:
-----------------------------------------
[~Apache9] - could you please go into more detail on how exposing a mutable
WALEdit to a coproc could "mess things up"? The comment in the code says
something similar, but doesn't give any example or principle explaining why
this is so, and I'd like to understand the argument.
I mean, the coproc could have a bug or malicious code which corrupts the
WALEdit, but any mutation pipeline coproc could do that by corrupting the
mutation object. Any read pipeline coproc hook could have buggy or malicious
code that replaced the scanner with one that returned nonsense. I get keeping
operation-level coprocessors away from process-level objects and services, but
WALEdit is an operation-level object just like mutations and scanners are.
> Add RegionObserver coprocessor hook for preWALAppend
> ----------------------------------------------------
>
> Key: HBASE-22623
> URL: https://issues.apache.org/jira/browse/HBASE-22623
> Project: HBase
> Issue Type: New Feature
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
>
> While many coprocessor hooks expose the WALEdit to implementing coprocs,
> there aren't any that expose the WALKey before it's created and added to the
> WALEntry.
> It's sometimes useful for coprocessors to be able to edit the WALKey, for
> example to add extended attributes using the fields to be added in
> HBASE-22622.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
