hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-3894) Thread contention over row locks set monitor
Date Wed, 18 May 2011 18:44:47 GMT

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

stack commented on HBASE-3894:

bq. On release, should we throw an exception if the client attempts to release a lock id that
doesn't exist, or just log it?

If client is getting what it asked for, then just log it.  How would it happen?

I like the idea of removing lockid completely (If client does explicity unlock, then they
deserve the headache that will ensue).

bq. When an HRegion is doing a miniBatch of thousands of rows, is it really best to attempt
to acquire thousands of locks and hold them all while doing the write?


> Thread contention over row locks set monitor
> --------------------------------------------
>                 Key: HBASE-3894
>                 URL: https://issues.apache.org/jira/browse/HBASE-3894
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2
>            Reporter: Dave Latham
>            Priority: Blocker
>             Fix For: 0.90.4
>         Attachments: concurrentRowLocks.patch, regionserver_rowLock_set_contention.threads.txt
> HRegion maintains a set of row locks.  Whenever any thread attempts to lock or release
a row it needs to acquire the monitor on that set.  We've been encountering cases with 30
handler threads all contending for that monitor, blocked progress on the region server.  Clients
timeout, and retry making it worse, and the region server stops responding to new clients
almost entirely.

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

View raw message