From hdfs-issues-return-268528-archive-asf-public=cust-asf.ponee.io@hadoop.apache.org Thu Jun 20 18:19:11 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id E3D7F180670 for ; Thu, 20 Jun 2019 20:19:10 +0200 (CEST) Received: (qmail 15446 invoked by uid 500); 20 Jun 2019 18:19:04 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 15283 invoked by uid 99); 20 Jun 2019 18:19:03 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Jun 2019 18:19:03 +0000 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 72A4AE2D76 for ; Thu, 20 Jun 2019 18:19:02 +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 2EAB425469 for ; Thu, 20 Jun 2019 18:19:01 +0000 (UTC) Date: Thu, 20 Jun 2019 18:19:01 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Work logged] (HDDS-1672) Improve locking in OzoneManager MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDDS-1672?focusedWorklogId=3D2= 63990&page=3Dcom.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpan= el#worklog-263990 ] ASF GitHub Bot logged work on HDDS-1672: ---------------------------------------- Author: ASF GitHub Bot Created on: 20/Jun/19 18:18 Start Date: 20/Jun/19 18:18 Worklog Time Spent: 10m=20 Work Description: anuengineer commented on pull request #949: HDDS-16= 72. Improve locking in OzoneManager. URL: https://github.com/apache/hadoop/pull/949#discussion_r295896363 =20 =20 ########## File path: hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/Oz= oneManagerLock.java ########## @@ -59,32 +68,39 @@ *
* {@literal ->} acquireVolumeLock (will work)
* {@literal +->} acquireBucketLock (will work)
- * {@literal +-->} acquireUserLock (will throw Exception)
+ * {@literal +-->} acquireS3BucketLock (will throw Exception)
*

*
- * To acquire a user lock you should not hold any Volume/Bucket lock. Simi= larly - * to acquire a Volume lock you should not hold any Bucket lock. + * To acquire a S3 lock you should not hold any Volume/Bucket lock. Simila= rly + * to acquire a Volume lock you should not hold any Bucket/User/S3 + * Secret/Prefix lock. */ public final class OzoneManagerLock { =20 + private static final Logger LOG =3D + LoggerFactory.getLogger(OzoneManagerLock.class); + + private static final String S3_BUCKET_LOCK =3D "s3BucketLock"; private static final String VOLUME_LOCK =3D "volumeLock"; private static final String BUCKET_LOCK =3D "bucketLock"; - private static final String PREFIX_LOCK =3D "prefixLock"; - private static final String S3_BUCKET_LOCK =3D "s3BucketLock"; + private static final String USER_LOCK =3D "userLock"; private static final String S3_SECRET_LOCK =3D "s3SecretetLock"; + private static final String PREFIX_LOCK =3D "prefixLock"; + =20 private final LockManager manager; =20 // To maintain locks held by current thread. private final ThreadLocal> myLocks =3D ThreadLocal.withInitial( - () -> ImmutableMap.of( - VOLUME_LOCK, new AtomicInteger(0), - BUCKET_LOCK, new AtomicInteger(0), - PREFIX_LOCK, new AtomicInteger(0), - S3_BUCKET_LOCK, new AtomicInteger(0), - S3_SECRET_LOCK, new AtomicInteger(0) - ) + () -> ImmutableMap.builder() + .put(S3_BUCKET_LOCK, new AtomicInteger(0)) + .put(VOLUME_LOCK, new AtomicInteger(0)) + .put(BUCKET_LOCK, new AtomicInteger(0)) + .put(USER_LOCK, new AtomicInteger(0)) + .put(S3_SECRET_LOCK, new AtomicInteger(0)) + .put(PREFIX_LOCK, new AtomicInteger(0)) + .build() =20 Review comment: Not a suggestion for this patch. But more of a question, should we just = maintain a bitset here, and just flip that bit up and down to see if the lo= ck is held. Or we can just maintain 32 bit integer, and we can easily find = if a lock is held by Xoring with the correct mask. I feel that might be sup= er efficient. @nandakumar131 . But as I said let us not do that in this pa= tch. =20 ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. =20 For queries about this service, please contact Infrastructure at: users@infra.apache.org Issue Time Tracking ------------------- Worklog Id: (was: 263990) Time Spent: 3h 50m (was: 3h 40m) > Improve locking in OzoneManager > ------------------------------- > > Key: HDDS-1672 > URL: https://issues.apache.org/jira/browse/HDDS-1672 > Project: Hadoop Distributed Data Store > Issue Type: Improvement > Components: Ozone Manager > Affects Versions: 0.4.0 > Reporter: Bharat Viswanadham > Assignee: Bharat Viswanadham > Priority: Major > Labels: pull-request-available > Attachments: Ozone Locks in OM.pdf > > Time Spent: 3h 50m > Remaining Estimate: 0h > > In this Jira, we shall follow the new lock ordering. In this way, in volu= me requests we can solve the issue of=C2=A0acquire/release/reacquire proble= m. And few bugs in the current implementation of S3Bucket/Volume operations= . > =C2=A0 > Currently after acquiring volume lock, we cannot acquire user lock.=C2=A0 > This is causing an issue in Volume request implementation, acquire/releas= e/reacquire volume lock. > =C2=A0 > Case of Delete Volume Request:=C2=A0 > # Acquire volume lock. > # Get Volume Info from DB > # Release Volume lock. (We are releasing the lock, because while acquiri= ng volume lock, we cannot acquire user lock0 > # Get owner from volume Info read from DB > # Acquire owner lock > # Acquire volume lock > # Do delete logic > # release volume lock > # release user lock > =C2=A0 > We can avoid this acquire/release/reacquire lock issue by making volume l= ock as low weight.=C2=A0 > =C2=A0 > In this way, the above deleteVolume request will change as below > # Acquire volume lock > # Get Volume Info from DB > # Get owner from volume Info read from DB > # Acquire owner lock > # Do delete logic > # release=C2=A0owner lock > # release volume lock.=C2=A0 > Same issue is seen with SetOwner for Volume request also. > During HDDS-1620 [~arp] brought up this issue.=C2=A0 > I am proposing the above solution to solve this issue. Any other idea/sug= gestions are welcome. > This also resolves a bug in setOwner for Volume request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org