[ https://issues.apache.org/jira/browse/HBASE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035580#comment-13035580 ]
stack commented on HBASE-3894: ------------------------------ On the patch, whats with all the ^Ms? Do we need HashedBytes? Was it you who said that wrapping the byte array in a ByteBuffer would do what we want? Otherwise, new class looks good (I think presence of this class will undo a bunch of places where we are using TreeMap just because key is a byte array). Whats up w/ this? {code} + private final ConcurrentHashMap<HashedBytes, CountDownLatch> lockedRows = + new ConcurrentHashMap<HashedBytes, CountDownLatch>(); {code} Interesting. You make the lockid long now instead of int. Good. Patch looks great Dave. Does it work? > 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