hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-3978) rowlock lease renew doesn't work when custom coprocessor/RegionObserver indicates to bypass default action
Date Sun, 12 Jun 2011 16:08:51 GMT

     [ https://issues.apache.org/jira/browse/HBASE-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Purtell resolved HBASE-3978.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.92.0
     Hadoop Flags: [Reviewed]

Committed after all local tests pass.

> rowlock lease renew doesn't work when custom coprocessor/RegionObserver indicates to
bypass default action
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3978
>                 URL: https://issues.apache.org/jira/browse/HBASE-3978
>             Project: HBase
>          Issue Type: Bug
>          Components: coprocessors, regionserver
>    Affects Versions: 0.92.0
>            Reporter: Ming Ma
>            Assignee: Ming Ma
>             Fix For: 0.92.0
>
>         Attachments: HBASE-3978-TRUNK.patch
>
>
> Region server will keep extending the lease on the rowlock as long as there is some action
on the row. This is done inside HRegionServer.getLockFromId, where it renew the lease on the
rowlock. However, when coprocessor "pre-action" observer is used, getLockFromId is skipped
if default action is bypassed. Take HRegionServer.exists as example, RegionCoprocessorHost.preExists
could return Boolean object if one of the regionobservers indicates default action should
be bypassed; thus getLockFromId didn't called and the lease on the lock doesn't get renewed.
>   public boolean exists(byte[] regionName, Get get) throws IOException {
>     checkOpen();
>     requestCount.incrementAndGet();
>     try {
>       HRegion region = getRegion(regionName);
>       if (region.getCoprocessorHost() != null) {
>         Boolean result = region.getCoprocessorHost().preExists(get);
>         if (result != null) {
>           return result.booleanValue();
>         }
>       }
>       Result r = region.get(get, getLockFromId(get.getLockId()));
>       boolean result = r != null && !r.isEmpty();
>       if (region.getCoprocessorHost() != null) {
>         result = region.getCoprocessorHost().postExists(get, result);
>       }
>       return result;
>     } catch (Throwable t) {
>       throw convertThrowableToIOE(cleanup(t));
>     }
>   }
> The application scenario is:
> a) client application passes in a rowlock object in an action.
> b) there is custom coprocessor/observer used.
> c) For a given action, the custom coprocessor/observer might tell coprocessor framework
to bypass the default action.
> From client application point of view, the behavior is sometimes the rowlock will timeout
even though client is accessing the row all the time, depending on whether coprocessor/observer
wants to bypass the default action.
> This applies to several other actions as well, increment, checkAndPut, checkandDelete.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message