[
https://issues.apache.org/jira/browse/HBASE-18474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-18474:
-----------------------------------
Description:
Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step
1.
{code}
// If we haven't got any rows in our batch, we should block to
// get the next one.
RowLock rowLock = null;
try {
rowLock = getRowLockInternal(mutation.getRow(), true);
} catch (TimeoutIOException e) {
// We will retry when other exceptions, but we should stop if we
timeout .
throw e;
} catch (IOException ioe) {
LOG.warn("Failed getting lock in batch put, row="
+ Bytes.toStringBinary(mutation.getRow()), ioe);
}
if (rowLock == null) {
// We failed to grab another lock
break; // stop acquiring more rows for this batch
} else {
acquiredRowLocks.add(rowLock);
}
{code}
Other code paths that apply mutations are acquiring write locks.
In HRegion#append
{code}
try {
rowLock = getRowLockInternal(row, false);
assert rowLock != null;
...
{code}
In HRegion#doIn
{code}
try {
rowLock = getRowLockInternal(increment.getRow(), false);
...
{code}
In HRegion#checkAndMutate
{code}
// Lock row - note that doBatchMutate will relock this row if called
RowLock rowLock = getRowLockInternal(get.getRow(), false);
// wait for all previous transactions to complete (with lock held)
mvcc.await();
{code}
In HRegion#processRowsWithLocks
{code}
// 2. Acquire the row lock(s)
acquiredRowLocks = new ArrayList<RowLock>(rowsToLock.size());
for (byte[] row : rowsToLock) {
// Attempt to lock all involved rows, throw if any lock times out
// use a writer lock for mixed reads and writes
acquiredRowLocks.add(getRowLockInternal(row, false));
}
{code}
and so on.
What doMiniBatchMutation is doing looks wrong.
was:
Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step
1.
{code}
// If we haven't got any rows in our batch, we should block to
// get the next one.
RowLock rowLock = null;
try {
rowLock = getRowLockInternal(mutation.getRow(), true);
} catch (TimeoutIOException e) {
// We will retry when other exceptions, but we should stop if we
timeout .
throw e;
} catch (IOException ioe) {
LOG.warn("Failed getting lock in batch put, row="
+ Bytes.toStringBinary(mutation.getRow()), ioe);
}
if (rowLock == null) {
// We failed to grab another lock
break; // stop acquiring more rows for this batch
} else {
acquiredRowLocks.add(rowLock);
}
{code}
Other code paths that apply mutations are acquiring write locks.
In HRegion#append
{code}
try {
rowLock = getRowLockInternal(row, false);
assert rowLock != null;
...
{code}
In HRegion#doIn
{code}
try {
rowLock = getRowLockInternal(increment.getRow(), false);
...
{code}
In HRegion#checkAndMutate
{code}
// Lock row - note that doBatchMutate will relock this row if called
RowLock rowLock = getRowLockInternal(get.getRow(), false);
// wait for all previous transactions to complete (with lock held)
mvcc.await();
{code}
What doMiniBatchMutation is doing looks wrong.
> HRegion#doMiniBatchMutation is acquiring read row locks
> -------------------------------------------------------
>
> Key: HBASE-18474
> URL: https://issues.apache.org/jira/browse/HBASE-18474
> Project: HBase
> Issue Type: Bug
> Reporter: Andrew Purtell
>
> Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in
> step 1.
> {code}
> // If we haven't got any rows in our batch, we should block to
>
> // get the next one.
>
> RowLock rowLock = null;
> try {
> rowLock = getRowLockInternal(mutation.getRow(), true);
> } catch (TimeoutIOException e) {
> // We will retry when other exceptions, but we should stop if we
> timeout .
> throw e;
> } catch (IOException ioe) {
> LOG.warn("Failed getting lock in batch put, row="
> + Bytes.toStringBinary(mutation.getRow()), ioe);
> }
> if (rowLock == null) {
> // We failed to grab another lock
>
> break; // stop acquiring more rows for this batch
>
> } else {
> acquiredRowLocks.add(rowLock);
> }
> {code}
> Other code paths that apply mutations are acquiring write locks.
> In HRegion#append
> {code}
> try {
> rowLock = getRowLockInternal(row, false);
> assert rowLock != null;
> ...
> {code}
> In HRegion#doIn
> {code}
> try {
> rowLock = getRowLockInternal(increment.getRow(), false);
> ...
> {code}
> In HRegion#checkAndMutate
> {code}
> // Lock row - note that doBatchMutate will relock this row if called
>
> RowLock rowLock = getRowLockInternal(get.getRow(), false);
> // wait for all previous transactions to complete (with lock held)
>
> mvcc.await();
> {code}
> In HRegion#processRowsWithLocks
> {code}
> // 2. Acquire the row lock(s)
>
> acquiredRowLocks = new ArrayList<RowLock>(rowsToLock.size());
> for (byte[] row : rowsToLock) {
> // Attempt to lock all involved rows, throw if any lock times out
>
> // use a writer lock for mixed reads and writes
>
> acquiredRowLocks.add(getRowLockInternal(row, false));
> }
> {code}
> and so on.
> What doMiniBatchMutation is doing looks wrong.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
