Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E569B200CBD for ; Thu, 6 Jul 2017 20:26:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id E3DDD16717B; Thu, 6 Jul 2017 18:26:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 15F30167179 for ; Thu, 6 Jul 2017 20:26:03 +0200 (CEST) Received: (qmail 87049 invoked by uid 500); 6 Jul 2017 18:26:03 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 87037 invoked by uid 99); 6 Jul 2017 18:26:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2017 18:26:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id AD09819173C for ; Thu, 6 Jul 2017 18:26:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id byHHdURW9JQs for ; Thu, 6 Jul 2017 18:26:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id D903B5F30B for ; Thu, 6 Jul 2017 18:26:00 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 5C1D2E0069 for ; Thu, 6 Jul 2017 18:26:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 1BFC020D1F for ; Thu, 6 Jul 2017 18:26:00 +0000 (UTC) Date: Thu, 6 Jul 2017 18:26:00 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (PHOENIX-3986) UngroupedAggregateRegionObserver.commitBatch() should set the index metadata as an attribute on every mutation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 06 Jul 2017 18:26:05 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16077010#comment-16077010 ] James Taylor edited comment on PHOENIX-3986 at 7/6/17 6:25 PM: --------------------------------------------------------------- +1 on your patch, [~tdsilva]. Can we file a separate JIRA for the wait logic for memstore size/flush and discuss there instead? was (Author: jamestaylor): 1 on your patch, [~tdsilva]. Can we file a separate JIRA for the wait logic for memstore size/flush and discuss there instead? > UngroupedAggregateRegionObserver.commitBatch() should set the index metadata as an attribute on every mutation > -------------------------------------------------------------------------------------------------------------- > > Key: PHOENIX-3986 > URL: https://issues.apache.org/jira/browse/PHOENIX-3986 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.9.0 > Reporter: Thomas D'Silva > Assignee: Thomas D'Silva > Fix For: 4.12.0, 4.11.1 > > Attachments: PHOENIX-3986.patch > > > We are seeing "unable to find cached index metadata" exceptions in production while running UPSERT SELECT queries on a table that has mutable indexes. These exceptions should not happen because PHOENIX-2935 changed the code to set the index metadata as an attribute. > {code} > ERROR 2008 (INT10): ERROR 2008 (INT10): Unable to find cached index metadata. key={} region={}.host={} Index update failed > at org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:81) > at org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:55) > at org.apache.phoenix.index.PhoenixIndexMetaData.getIndexMetaData(PhoenixIndexMetaData.java:86) > at org.apache.phoenix.index.PhoenixIndexMetaData.(PhoenixIndexMetaData.java:94) > at org.apache.phoenix.index.PhoenixIndexBuilder.getIndexMetaData(PhoenixIndexBuilder.java:93) > at org.apache.phoenix.hbase.index.builder.IndexBuildManager.getIndexUpdate(IndexBuildManager.java:122) > at org.apache.phoenix.hbase.index.Indexer.preBatchMutateWithExceptions(Indexer.java:324) > at org.apache.phoenix.hbase.index.Indexer.preBatchMutate(Indexer.java:249) > at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$35.call(RegionCoprocessorHost.java:996) > at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1621) > at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1697) > at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1653) > at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preBatchMutate(RegionCoprocessorHost.java:992) > at org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2650) > at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2410) > at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2365) > at org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver.commitBatch(UngroupedAggregateRegionObserver.java:216) > at org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver.commit(UngroupedAggregateRegionObserver.java:791) > at org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver.doPostScannerOpen(UngroupedAggregateRegionObserver.java:721) > at org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.overrideDelegate(BaseScannerRegionObserver.java:236) > at org.apache.phoenix.coprocessor.BaseScannerRegionObserver$RegionScannerHolder.nextRaw(BaseScannerRegionObserver.java:287) > at org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3361) > at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32492) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2210) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104) > at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108) > at java.lang.Thread.run(Thread.java:745) > {code} > This is what I think is happening : > In UngroupedAggregateRegionObserver.doPostScannerOpen we commit batches of mutations. > In commitBatch() since the mutations are for the same region we only set the index maintainer as an attribute on the first mutation of the batch. We then call HRegion.batchMutate() which ends up calling HRegion.doMiniBatchMutation() in a loop. > doMiniBatchMutation() loops throught the mutations one at a time and tries to acquire the each mutation's lock. If it cannot acquire a lock it processes the mutations for which it has acquired locks so far and then calls coprocessorHost.preBatchMutate which eventually ends up calling PhoenixIndexBuilder.getIndexMetaData() which set the index metadata using the attribute map of the first mutation in the mini batch. > It then processes the next set of mutations for which it has acquired locks. The index metadata is not set as an attribute for this next mini batch, so we try and look it up in the cache which fails > In PhoenixIndexBuilder > {code} > @Override > public IndexMetaData getIndexMetaData(MiniBatchOperationInProgress miniBatchOp) throws IOException { > return new PhoenixIndexMetaData(env, miniBatchOp.getOperation(0).getAttributesMap()); > } > {code} > In MiniBatchOperationInProgress > {code} > /** > * @param index > * @return The operation(Mutation) at the specified position. > */ > public T getOperation(int index) { > return operations[getAbsoluteIndex(index)]; > } > private int getAbsoluteIndex(int index) { > if (index < 0 || this.firstIndex + index >= this.lastIndexExclusive) { > throw new ArrayIndexOutOfBoundsException(index); > } > return this.firstIndex + index; > } > {code} > [~ankit.singhal] [~jamestaylor] Does this make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029)