[ 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