[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902234#comment-16902234
]
Andrew Purtell edited comment on HBASE-22623 at 8/7/19 4:46 PM:
----------------------------------------------------------------
I have to agree. I can call System.exit() from a coprocessor. That doesn't mean
it is a good idea. A necessary precondition for coprocessor API use is an
understanding you are messing with internals. It's not meant for arbitrary user
code or user development. We don't need to protect against dumb users. What we
can/should protect is our ability to change internal interfaces, so if there is
a concern there that would certainly be valid. However these classes - WALKey
and WALEdit - are both already LP(coproc). We are discussing if an add() method
should be available or not and going right to a maximally restrictive position
which is in my opinion inappropriate given the context. Coprocessor interfaces
are meant to change things on the line between internal-only and extensible.
This JIRA seeks to make WAL objects more extensible for coprocessors, by giving
coprocessors a chance to change them *once* before they are committed to the
WAL, and this is motivated by a real world example waiting over in Phoenix.
This is a carefully considered change and very small in scope. It is exactly
what we have CP interfaces for elsewhere. I think [~Apache9]'s position is not
reasonable given this context, but he is entitled to his opinion. I hope he
will consider changing it, though.
was (Author: apurtell):
I have to agree. I can call System.exit() from a coprocessor. That doesn't mean
it is a good idea. A necessary precondition for coprocessor API use is an
understanding you are messing with internals. It's not meant for arbitrary user
code or user development. We don't need to protect against dumb users. What we
can/should protect is our ability to change internal interfaces, so if there is
a concern there that would certainly be valid. However these classes - WALKey
and WALEdit - are both already LP(coproc). We are discussing if an add() method
should be available or not and going right to a maximally restrictive position
which is in my opinion inappropriate given the context. Coprocessor interfaces
are meant to change things on the line between internal-only and extensible.
This JIRA seeks to make WAL objects more extensible for coprocessors, by giving
coprocessors a change to change them *once* before they are committed to the
WAL, and this is motivated by a real world example waiting over in Phoenix.
This is a carefully considered change and very small in scope. It is exactly
what we have CP interfaces for elsewhere. I think [~Apache9]'s position is not
reasonable given this context, but he is entitled to his opinion. I hope he
will consider changing it, though.
> 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)
