[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901668#comment-16901668
]
Geoffrey Jacoby edited comment on HBASE-22623 at 8/7/19 3:39 AM:
-----------------------------------------------------------------
[~Apache9] - that seems like an argument that the new coproc hook shouldn't
fire for "meta" WALEdits, just ones associated with user operations, rather
than an argument against not exposing mutable WALEdit to coprocs in general. If
we were to take that approach, would that just require a check to
WALEdit.isMetaEdit(), or can user and system level Cells be interleaved in the
same Edit?
To your second point, every single coprocessor hook in HBase can be used to
"break the logic of HBase", by their very nature, because an evil coproc
developer can say "Thread.sleep(Long.MAX_VALUE)", "System.exit(1)", or even
start deleting WAL or data directories. An operator who runs a coprocessor is
trusting the coproc to the same extent they trust HBase.
IMO we should be making it easy to do useful things correctly, and harder to do
bad things accidentally, but we're never going to make coprocessors as they
exist now completely safe.
was (Author: gjacoby):
[~Apache9] - that seems like an argument that the new coproc hook shouldn't
fire for "meta" WALEdits, just ones associated with user operations, rather
than an argument against not exposing mutable WALEdit to coprocs in general. If
we were to take that approach, would that just require a check to
WALEdit.isMetaEdit(), or can user and system level Cells be interleaved in the
same Edit?
To your second point, every single coprocessor hook in HBase can be used to
"break the logic of HBase", by their very nature, because an evil coproc
developer can say "Thread.sleep(Long.MAX_VALUE)", "System.exit(1)", or even
start deleting WAL or data directories. An operator who runs a coprocessor is
trusting the coproc to the same extent they trust HBase.
IMO we should be making it easy to do useful things correctly, and harder to do
bad things accidentally, but we're never going to make coprocessors as they
exist now "safe".
> 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)
