[ https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973270#comment-15973270 ]
Andrew Purtell commented on HBASE-17924: ---------------------------------------- Test failure looks related to patch. org.apache.hadoop.hbase.wal.WALSplitter$MutationReplay defines compareTo(WALSplitter$MutationReplay) and uses Object.equals() At WALSplitter.java:Object.equals() At WALSplitter.java:[line 2301] > 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 > > Attachments: HBASE-17924.patch, HBASE-17924.v0.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)