hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11126) Add RegionObserver pre hooks that operate under row lock
Date Fri, 30 May 2014 17:07:03 GMT

    [ https://issues.apache.org/jira/browse/HBASE-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013947#comment-14013947

Anoop Sam John commented on HBASE-11126:

+  public void prePrepareTimeStampForDeleteVersion(
+      final ObserverContext<RegionCoprocessorEnvironment> e, final Mutation delete,
+      final Cell cell, final byte[] byteNow, final byte[] family, final Get get) throws IOException
+  }
When we pass cell already, no need for family again.

In javadoc of RegionObserver#prePrepareTimeStampForDeleteVersion
" * Called before the server updates the timestamp for delete Columns with latest timestamp."
But this hook is not called for all cases of latest TS. Only when it is a version delete.

+   * @param isInReplay 
    * @throws IOException
-  void prepareDeleteTimestamps(Map<byte[], List<Cell>> familyMap, byte[] byteNow)
-      throws IOException {
+  void prepareDeleteTimestamps(Mutation mutation, Map<byte[], List<Cell>> familyMap,

+      byte[] byteNow) throws IOException {
This param is not there in method args - isInReplay

> Add RegionObserver pre hooks that operate under row lock
> --------------------------------------------------------
>                 Key: HBASE-11126
>                 URL: https://issues.apache.org/jira/browse/HBASE-11126
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.99.0, 0.98.3
>            Reporter: Andrew Purtell
>            Assignee: ramkrishna.s.vasudevan
>         Attachments: HBASE-11126.patch, HBASE-11126_1.patch, HBASE-11126_4.patch, HBASE-11126_5.patch,
HBASE-11126_new_2.patch, HBASE-11126_new_3.patch
> The coprocessor hooks were placed outside of row locks. This was meant to sidestep performance
issues arising from significant work done within hook invocations. However as the security
code increases in sophistication we are now running into concurrency issues trying to use
them as a result of that early decision. Since the initial introduction of coprocessor upcalls
there has been some significant refactoring done around them and concurrency control in core
has become more complex. This is potentially an issue for many coprocessor users.
> We should do either:\\
> - Move all existing RegionObserver pre* hooks to execute under row lock.
> - Introduce a new set of RegionObserver pre* hooks that execute under row lock, named
to indicate such.
> The second option is less likely to lead to surprises.
> All RegionObserver hook Javadoc should be updated with advice to the coprocessor implementor
not to take their own row locks in the hook. If the current thread happens to already have
a row lock and they try to take a lock on another row, there is a deadlock risk.
> As always a drawback of adding hooks is the potential for performance impact. We should
benchmark the impact and decide if the second option above is a viable choice or if the first
option is required.
> Finally, we should introduce a higher level interface for managing the registration of
'user' code for execution from the low level hooks. I filed HBASE-11125 to discuss this further.

This message was sent by Atlassian JIRA

View raw message