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 DEBEC200CAC for ; Mon, 19 Jun 2017 18:52:10 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id DDED0160BE4; Mon, 19 Jun 2017 16:52:10 +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 2EC83160BE1 for ; Mon, 19 Jun 2017 18:52:10 +0200 (CEST) Received: (qmail 7986 invoked by uid 500); 19 Jun 2017 16:52:09 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 7972 invoked by uid 99); 19 Jun 2017 16:52:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jun 2017 16:52:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id C5EEA1B0B33 for ; Mon, 19 Jun 2017 16:52:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-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 (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id R-ygkA-9QJvP for ; Mon, 19 Jun 2017 16:52:08 +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 F28265FC6C for ; Mon, 19 Jun 2017 16:52:06 +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 9C485E0DE9 for ; Mon, 19 Jun 2017 16:52:04 +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 DD89C24006 for ; Mon, 19 Jun 2017 16:52:00 +0000 (UTC) Date: Mon, 19 Jun 2017 16:52:00 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 19 Jun 2017 16:52:11 -0000 [ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054309#comment-16054309 ] stack commented on HBASE-18233: ------------------------------- bq. Increment request in mid of a batch request would be "another thread", and I think the logic could work well here. We're not expecting this getRowLock to be the "only path" to get the row lock, but just one way. It's ok to conflict with other threads, we will return what it should be: a read/write lock if no contention or null if could not obtain the lock, only not that exclusive. Ok. Sounds good. Is it possible to add a test for threads coming via a route that is concurrent and NOT the batch route to prove all works as expected? bq. Oh maybe some misunderstanding here. Yes. Thank you for fixing my misunderstanding. What about this question: "Where is the benefit? The benefit is that if some one comes through looking for a write lock, first we'll flush any read lock batches? Any benefit seen?" Is the benefit that we no longer block? That we make-do with however many locks we were able to attain? Any benefit seen in testing? This work is starting to look real nice. Thanks lads. > We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock > ------------------------------------------------------------------------- > > Key: HBASE-18233 > URL: https://issues.apache.org/jira/browse/HBASE-18233 > Project: HBase > Issue Type: Bug > Affects Versions: 1.2.7 > Reporter: Allan Yang > Assignee: Allan Yang > Attachments: HBASE-18233-branch-1.2.patch > > > Please refer to the discuss in HBASE-18144 > https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701 -- This message was sent by Atlassian JIRA (v6.4.14#64029)