[ https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020833#comment-16020833 ]
Hudson commented on HBASE-17924: -------------------------------- FAILURE: Integrated in Jenkins build HBase-HBASE-14614 #244 (See [https://builds.apache.org/job/HBase-HBASE-14614/244/]) HBASE-17924 Consider sorting the row order when processing multi() ops (apurtell: rev 959deb0e5c7c43c2cda6fe4b5c4d46ed80d3d8e6) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALSplitter.java > Consider sorting the row order when processing multi() ops before taking > rowlocks > --------------------------------------------------------------------------------- > > Key: HBASE-17924 > URL: https://issues.apache.org/jira/browse/HBASE-17924 > Project: HBase > Issue Type: Improvement > Affects Versions: 2.0.0, 1.1.8 > Reporter: Andrew Purtell > Assignee: Allan Yang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17924.patch, HBASE-17924.v0.patch, > HBASE-17924.v2.patch, HBASE-17924.v3.patch, HBASE-17924.v4.patch, > HBASE-17924.v5.patch > > > When processing a batch mutation, we take row locks in whatever order the > mutations were added to the multi op by the client. > > {noformat} > RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow -> > HRegion#mutateRowsWithLocks -> HRegion#processRowsWithLocks > {noformat} > Or > {noformat} > RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation -> > HRegion#get > | HRegion#append > | HRegion#increment > | HRegionServer#doBatchOp -> HRegion#batchMutate -> > HRegion#doMiniBatchMutation > {noformat} > > multi() is fed by client APIs that accept a RowMutations object containing > actions for multiple rows. The container for ops inside RowMutations is an > ArrayList, which doesn't change the ordering of objects added to it. The > protobuf implementation of the messages for multi ops do not reorder the list > of actions. When processing multi ops we iterate over the actions in the > order rehydrated from protobuf. > We should discuss sorting the order of ops by row key when processing multi() > ops before taking row locks. Does this make lock ordering more predictable > for server side operations? Yes, but potentially surprising for the client, > right? Is there any legitimate reason we should take locks out of row key > sorted order because the client has structured the request as such? -- This message was sent by Atlassian JIRA (v6.3.15#6346)