RE: [ANNOUNCE] New HBase committer Abhishek Singh Chouhan
Congratulations Abhishek..!! Thanks & Regards, Pankaj HUAWEI TECHNOLOGIES CO.LTD. Huawei Tecnologies India Pvt. Ltd. Near EPIP Industrial Area, Kundalahalli Village Whitefield, Bangalore-560066 www.huawei.com - This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Saturday, July 29, 2017 6:32 AM To: dev@hbase.apache.org; u...@hbase.apache.org Subject: [ANNOUNCE] New HBase committer Abhishek Singh Chouhan On behalf of the Apache HBase PMC, I am pleased to announce that Abhishek Singh Chouhan has accepted the PMC's invitation to become a committer on the project. We appreciate all of Abhishek's great work thus far and look forward to continued involvement. Please join me in congratulating Abhishek! -- Best regards, Andrew
RE: [ANNOUNCE] New HBase committer Vikas Vishwakarma
Congratulations Vikas..!! Thanks & Regards, Pankaj HUAWEI TECHNOLOGIES CO.LTD. Huawei Tecnologies India Pvt. Ltd. Near EPIP Industrial Area, Kundalahalli Village Whitefield, Bangalore-560066 www.huawei.com - This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Saturday, July 29, 2017 6:33 AM To: dev@hbase.apache.org; u...@hbase.apache.org Subject: [ANNOUNCE] New HBase committer Vikas Vishwakarma On behalf of the Apache HBase PMC, I am pleased to announce that Vikas Vishwakarma has accepted the PMC's invitation to become a committer on the project. We appreciate all of Vikas's great work thus far and look forward to continued involvement. Please join me in congratulating Vikas! -- Best regards, Andrew
[jira] [Resolved] (HBASE-18474) HRegion#doMiniBatchMutation is acquiring read row locks
[
https://issues.apache.org/jira/browse/HBASE-18474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-18474.
Resolution: Not A Problem
> 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(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)
[jira] [Created] (HBASE-18482) Enable state to be passed between the batch mutate coprocessors
James Taylor created HBASE-18482: Summary: Enable state to be passed between the batch mutate coprocessors Key: HBASE-18482 URL: https://issues.apache.org/jira/browse/HBASE-18482 Project: HBase Issue Type: Improvement Reporter: James Taylor For secondary indexing, Phoenix leverages the coprocessors that fire during the processing of a batch mutate: preBatchMutate, postBatchMutate, and postBatchMutateIndispensably. It would be very helpful if we had a way of passing state between these calls. One solution would be to provide a member variable in the MiniBatchOperationInProgress class that gets passed from invocation to invocation. Within doMiniBatchMutation, the instantiation of the MiniBatchOperationInProgress would simply set this context member variable based on the value from the previous MiniBatchOperationInProgress instantiation. Another solution would be to allow the a context object to be set on the ObserverContext which would then be available to the other calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (HBASE-18259) HBase book link to "beginner" issues includes resolved issues
[ https://issues.apache.org/jira/browse/HBASE-18259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reopened HBASE-18259: > HBase book link to "beginner" issues includes resolved issues > - > > Key: HBASE-18259 > URL: https://issues.apache.org/jira/browse/HBASE-18259 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Mike Drob >Assignee: Peter Somogyi > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18259.master.001.patch > > > The link at http://hbase.apache.org/book.html#getting.involved for beginner > issues is > https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner) > but this includes resolved issues as well, which is not useful to folks > looking for new issues to cut their teeth on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-6322) Unnecessary creation of finalizers in HTablePool
[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-6322. -- Resolution: Invalid Resolving as no longer valid (assigning to Chia...) > Unnecessary creation of finalizers in HTablePool > > > Key: HBASE-6322 > URL: https://issues.apache.org/jira/browse/HBASE-6322 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.92.0, 0.92.1, 0.94.0 >Reporter: Ryan Brush > Attachments: HBASE-6322-0.92.1.patch, HBASE-6322-trunk.1.patch > > > From a mailing list question: > While generating some load against a library that makes extensive use of > HTablePool in 0.92, I noticed that the largest heap consumer was > java.lang.ref.Finalizer. Digging in, I discovered that HTablePool's internal > PooledHTable extends HTable, which instantiates a ThreadPoolExecutor and > supporting objects every time a pooled HTable is retrieved. Since > ThreadPoolExecutor has a finalizer, it and its dependencies can't get garbage > collected until the finalizer runs. The result is by using HTablePool, we're > creating a ton of objects to be finalized that are stuck on the heap longer > than they should be, creating our largest source of pressure on the garbage > collector. It looks like this will also be a problem in 0.94 and trunk. > The easy fix is just to have PooledHTable implement HTableInterface (rather > than subclass HTable), but this does break a unit test that explicitly checks > that PooledHTable implements HTable -- I can only assume this test is there > for some historical passivity reason. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-6903) HLog.Entry implements Writable; change to pb
[ https://issues.apache.org/jira/browse/HBASE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-6903. -- Resolution: Invalid Assignee: Chia-Ping Tsai Resolving as no longer relevant. Assigning to Chia > HLog.Entry implements Writable; change to pb > > > Key: HBASE-6903 > URL: https://issues.apache.org/jira/browse/HBASE-6903 > Project: HBase > Issue Type: Task > Components: wal >Reporter: stack >Assignee: Chia-Ping Tsai > > Can we do this in a way that makes it so even after 0.96, we can read old > WALs? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18481) The autoFlush flag was not used in PE tool
Guanghao Zhang created HBASE-18481: -- Summary: The autoFlush flag was not used in PE tool Key: HBASE-18481 URL: https://issues.apache.org/jira/browse/HBASE-18481 Project: HBase Issue Type: Bug Reporter: Guanghao Zhang Priority: Minor After HBASE-12728, PE used the BufferedMutator for random/sequential write test and the autoFlush flag was not used. So all write test will buffered the write request and send as a batch request when the buffer has filled. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18480) The cost of BaseLoadBalancer.cluster is changed even if the rollback is done
Chia-Ping Tsai created HBASE-18480: -- Summary: The cost of BaseLoadBalancer.cluster is changed even if the rollback is done Key: HBASE-18480 URL: https://issues.apache.org/jira/browse/HBASE-18480 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai If the cost of cluster isn't restored after the undo action, StochasticLoadBalancer will be hard to generate the "good" action to balance the cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
