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 53B2D200CAC for ; Mon, 19 Jun 2017 08:30:10 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 525DC160BEC; Mon, 19 Jun 2017 06:30: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 95986160BE1 for ; Mon, 19 Jun 2017 08:30:09 +0200 (CEST) Received: (qmail 57273 invoked by uid 500); 19 Jun 2017 06:30:08 -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 57262 invoked by uid 99); 19 Jun 2017 06:30:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jun 2017 06:30:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 0BE37C03A3 for ; Mon, 19 Jun 2017 06:30:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 9IwbM2bntP4t for ; Mon, 19 Jun 2017 06:30:07 +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 83EC75FC99 for ; Mon, 19 Jun 2017 06:30: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 4F3C0E0DBF for ; Mon, 19 Jun 2017 06:30: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 AC0AA24009 for ; Mon, 19 Jun 2017 06:30:01 +0000 (UTC) Date: Mon, 19 Jun 2017 06:30:01 +0000 (UTC) From: "Yu Li (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 06:30:10 -0000 [ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053521#comment-16053521 ] Yu Li commented on HBASE-18233: ------------------------------- bq. If a thread comes in via another path, will it mess up the expectation here? Please correct me if I'm wrong boss: 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. bq. In the else below, we ask NOT to wait for lock but doesn't the tryLock call block until it gets the lock; i.e. we are blocking until we get the read lock. Oh maybe some misunderstanding here. From javadoc of {{Lock.tryLock()}}: {code} Acquires the lock only if it is free at the time of invocation. Acquires the lock if it is available and returns immediately with the value true. If the lock is not available then this method will return immediately with the value false. {code} We won't wait given no timeout. > 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)