hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Warrington (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4077) Deadlock if WrongRegionException is thrown from getLock in HRegion.delete
Date Thu, 07 Jul 2011 20:39:18 GMT

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

Adam Warrington commented on HBASE-4077:
----------------------------------------

I followed the same pattern used in the other update functions in HRegion, which include:

checkAndMutate
put
increment
incrementColumnValue

I originally did a check against null, but after looking through the code, decided consistency
with the other functions was something I liked better. I'm in no way married to this, so I
am game to change it to a null check if that is what folks want. Let me know.

> Deadlock if WrongRegionException is thrown from getLock in HRegion.delete
> -------------------------------------------------------------------------
>
>                 Key: HBASE-4077
>                 URL: https://issues.apache.org/jira/browse/HBASE-4077
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.90.3
>            Reporter: Adam Warrington
>            Priority: Critical
>         Attachments: HBASE-4077-0.patch
>
>
> In the HRegion.delete function, If getLock throws a WrongRegionException, no lock id
is ever returned, yet in the finally block, it tries to release the row lock using that lock
id (which is null). This causes an NPE in the finally clause, and the closeRegionOperation()
to never execute, keeping a read lock open forever.
> ERROR org.apache.hadoop.hbase.regionserver.HRegionServer: 
> java.lang.NullPointerException 
> at org.apache.hadoop.hbase.util.Bytes.compareTo(Bytes.java:840) 
> at org.apache.hadoop.hbase.util.Bytes$ByteArrayComparator.compare(Bytes.java:108) 
> at org.apache.hadoop.hbase.util.Bytes$ByteArrayComparator.compare(Bytes.java:100) 
> at java.util.TreeMap.getEntryUsingComparator(TreeMap.java:351) 
> at java.util.TreeMap.getEntry(TreeMap.java:322) 
> at java.util.TreeMap.remove(TreeMap.java:580) 
> at java.util.TreeSet.remove(TreeSet.java:259) 
> at org.apache.hadoop.hbase.regionserver.HRegion.releaseRowLock(HRegion.java:2145) 
> at org.apache.hadoop.hbase.regionserver.HRegion.delete(HRegion.java:1174) 
> at org.apache.hadoop.hbase.regionserver.HRegionServer.delete(HRegionServer.java:1914)

> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) 
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

> at java.lang.reflect.Method.invoke(Method.java:597) 
> at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) 
> at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)
> When the region later attempts to close, the write lock can never be acquired, and the
region remains in transition forever.

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

        

Mime
View raw message