[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900145#comment-16900145
]
Geoffrey Jacoby edited comment on HBASE-22623 at 8/6/19 1:04 AM:
-----------------------------------------------------------------
So, I see that the immutability of the Region-created WALEdit is an explicit
goal of the current code, but what I'm trying to understand is _why_.
Immutability can be a wonderful thing; it lets you write idempotent code along
functional principles where methods have no side effects, just an output. But
it seems to me the entire point of coprocessors _is to have side effects_.
I'm sure we could come up with an indirect way to accomplish the adding of
cells -- maybe something like WALEdit or List<Cell> preWALAppend(WALKey,
WALEditSuperInterfaceWithoutAddMethods edit), where HRegion then takes the
returned new WALEdit or List<Cell> and combines its Cells with the Cells of the
existing WALEdit -- but I don't see what the added complexity achieves. It
would just be more object churn for the garbage collector.
Because coprocessors are embedded in core HBase logic, an operator is
explicitly trusting the coproc author to get things right. It's good for the
framework to make it easy to do the right thing, and guide people away from
doing wrong or risky things. However, the messiest coproc-related bugs I've
seen (both in Phoenix and some proprietary coprocs) have come from the hooks
that are actually the most immutable: resource leaks from trying to recreate
various types of scanners because setters aren't available. Not suggesting we
change those hooks, just illustrating that immutable doesn't automatically mean
"safe" or "easy" and mutable doesn't automatically mean "risky".
It all depends on context. So I'm very curious what the context is here that
makes the idea of changing the HRegion WALEdit directly risky, if changing it
indirectly is OK.
was (Author: gjacoby):
So, I see that the immutability of the Region-created WALEdit is an explicit
goal of the current code, but what I'm trying to understand is _why_.
Immutability can be a wonderful thing; it lets you write idempotent code along
functional principles where code has no side effects, just an output. But it
seems to me the entire point of coprocessors _is to have side effects_.
I'm sure we could come up with an indirect way to accomplish the adding of
cells -- maybe something like WALEdit preWALAppend(WALKey,
WALEditSuperInterfaceWithoutAddMethods edit), where HRegion then takes the
returned new WALEdit and combines its Cells with the Cells of the existing
WALEdit -- but I don't see what the added complexity achieves. It would just be
more object churn for the garbage collector.
> 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)
