Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-17924

Consider sorting the row order when processing multi() ops before taking rowlocks

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.8, 2.0.0
    • Fix Version/s: 1.4.0, 1.3.3, 2.0.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      When processing a batch mutation, we take row locks in whatever order the mutations were added to the multi op by the client.

      RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow -> HRegion#mutateRowsWithLocks -> HRegion#processRowsWithLocks
      

      Or

      RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
            HRegion#get 
          | HRegion#append 
          | HRegion#increment 
          | HRegionServer#doBatchOp -> HRegion#batchMutate -> HRegion#doMiniBatchMutation
      

      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?

        Attachments

        1. HBASE-17924.patch
          2 kB
          Allan Yang
        2. HBASE-17924.v0.patch
          2 kB
          Allan Yang
        3. HBASE-17924.v2.patch
          5 kB
          Allan Yang
        4. HBASE-17924.v3.patch
          4 kB
          Allan Yang
        5. HBASE-17924.v4.patch
          4 kB
          Allan Yang
        6. HBASE-17924.v5.patch
          5 kB
          Allan Yang

          Activity

            People

            • Assignee:
              allan163 Allan Yang
              Reporter:
              apurtell Andrew Kyle Purtell
            • Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: