Hi, Currently Region.processRowsWithLocks() API takes o.a.h.h.regionserver.RowProcessor as an argument and only implementation of this class is MultiRowMutationProcessor. This implementation is internal and used from HRegion.mutateRows...() methods.
HRegion.processRowsWithLocks() implementation, doesn't call coprocessor hooks but instead calls RowProcessor hooks at appropriate point in execution. Many of these hooks/ methods have same names and are called at similar points during the course of execution but they are not related! HRegion.batchMutate() methods call coprocessor hooks but not row RowProcessor hooks. Internal implementation MultiRowMutationProcessor, call coprocessor hooks from inside it's own methods/ hooks. But this can not be expected of all implementations for RowProcessors. In case of HRegion.batchMutate...() methods, CP mutations are merged with input mutations and these merged mutations are applied to WALEdit fetched from CPs. In case of processRowsWithLocks(), mutations are fetched from RowProcessor instance and are applied on WALEdit built by RowProcessor. The major inconsistency here is, one code path uses coprocessors while other uses RowProcessor. There are other minor inconsistencies along those two code paths. Proposed fix: * Unify two code paths. * Deprecate RowProcessor and API Region.processRowsWithLocks() that takes RowProcessor as an argument. * Provide alternate API that doesn't take RowProcessor. * Modify batchMutate...() to take additional arguments: rowsToLock (byte[][]) and atomic/ allOrNone (boolean). * Remove MultiRowMutationProcessor. Make HRegion.mutateRows() methods to use batchMutate(). * Make new implementation of Region.processRowsWithLocks() which doesn't take RowProcessor as an argument use batchMutate(). Suggestion is that coprocessors can be used to do things RowProcessors are doing. Related JIRAs: HBASE-18703, HBASE-18183 Let me know your thoughts. Thanks, Umesh
