[
https://issues.apache.org/jira/browse/HDDS-1723?focusedWorklogId=266294&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-266294
]
ASF GitHub Bot logged work on HDDS-1723:
----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jun/19 02:45
Start Date: 25/Jun/19 02:45
Worklog Time Spent: 10m
Work Description: anuengineer commented on pull request #1006: HDDS-1723.
Create new OzoneManagerLock class.
URL: https://github.com/apache/hadoop/pull/1006#discussion_r296983712
##########
File path:
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/lock/OzoneManagerLock.java
##########
@@ -0,0 +1,336 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.hadoop.ozone.om.lock;
+
+
+import java.util.ArrayList;
+import java.util.List;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.ozone.lock.LockManager;
+
+/**
+ * Provides different locks to handle concurrency in OzoneMaster.
+ * We also maintain lock hierarchy, based on the weight.
+ *
+ * <table>
+ * <caption></caption>
+ * <tr>
+ * <td><b> WEIGHT </b></td> <td><b> LOCK </b></td>
+ * </tr>
+ * <tr>
+ * <td> 0 </td> <td> S3 Bucket Lock </td>
+ * </tr>
+ * <tr>
+ * <td> 1 </td> <td> Volume Lock </td>
+ * </tr>
+ * <tr>
+ * <td> 2 </td> <td> Bucket Lock </td>
+ * </tr>
+ * <tr>
+ * <td> 3 </td> <td> User Lock </td>
+ * </tr>
+ * <tr>
+ * <td> 4 </td> <td> S3 Secret Lock</td>
+ * </tr>
+ * <tr>
+ * <td> 5 </td> <td> Prefix Lock </td>
+ * </tr>
+ * </table>
+ *
+ * One cannot obtain a lower weight lock while holding a lock with higher
+ * weight. The other way around is possible. <br>
+ * <br>
+ * <p>
+ * For example:
+ * <br>
+ * {@literal ->} acquire volume lock (will work)<br>
+ * {@literal +->} acquire bucket lock (will work)<br>
+ * {@literal +-->} acquire s3 bucket lock (will throw Exception)<br>
+ * </p>
+ * <br>
+ */
+
+public class OzoneManagerLock {
+
+ private static final Logger LOG =
+ LoggerFactory.getLogger(OzoneManagerLock.class);
+
+ private final LockManager<String> manager;
+ private final ThreadLocal<Short> lockSet = ThreadLocal.withInitial(
+ () -> Short.valueOf((short)0));
+
+
+ /**
+ * Creates new OzoneManagerLock instance.
+ * @param conf Configuration object
+ */
+ public OzoneManagerLock(Configuration conf) {
+ manager = new LockManager<>(conf);
+ }
+
+ /**
+ * Acquire lock on resource.
+ *
+ * For S3_Bucket, VOLUME, BUCKET type resource, same thread acquiring lock
+ * again is allowed.
+ *
+ * For USER, PREFIX, S3_SECRET type resource, same thread acquiring lock
+ * again is not allowed.
+ *
+ * Special Note for UserLock: Single thread can acquire single user lock/
+ * multi user lock. But not both at the same time.
+ * @param resourceName - Resource name on which user want to acquire lock.
+ * @param resource - Type of the resource.
+ */
+ public void acquireLock(String resourceName, Resource resource) {
+ if (!resource.canLock(lockSet.get())) {
+ String errorMessage = getErrorMessage(resource);
+ LOG.error(errorMessage);
+ throw new RuntimeException(errorMessage);
+ } else {
+ manager.lock(resourceName);
+ lockSet.set(resource.setLock(lockSet.get()));
+ }
+ }
+
+ private String getErrorMessage(Resource resource) {
+ return "Thread '" + Thread.currentThread().getName() + "' cannot " +
+ "acquire " + resource.name + " lock while holding " +
+ getCurrentLocks().toString() + " lock(s).";
+
+ }
+
+ private List<String> getCurrentLocks() {
+ List<String> currentLocks = new ArrayList<>();
+ int i=0;
+ short lockSetVal = lockSet.get();
+ for (Resource value : Resource.values()) {
+ if (value.isLevelLocked(lockSetVal)) {
+ currentLocks.add(value.getName());
+ }
+ }
+ return currentLocks;
+ }
+
+ /**
+ * Acquire lock on multiple users.
+ * @param oldUserResource
+ * @param newUserResource
+ */
+ public void acquireMultiUserLock(String oldUserResource,
+ String newUserResource) {
+ Resource resource = Resource.USER;
+ if (!resource.canLock(lockSet.get())) {
+ String errorMessage = getErrorMessage(resource);
+ LOG.error(errorMessage);
+ throw new RuntimeException(errorMessage);
+ } else {
+ // When acquiring multiple user locks, the reason for doing lexical
+ // order comparision is to avoid deadlock scenario.
+
+ // Example: 1st thread acquire lock(ozone, hdfs)
+ // 2nd thread acquire lock(hdfs, ozone).
+ // If we don't acquire user locks in an order, there can be a deadlock.
+
+ // 1st thread acquired lock on ozone, waiting for lock on hdfs, 2nd
+ // thread acquired lock on hdfs, waiting for lock on ozone.
+ // To avoid this when we acquire lock on multiple users, we acquire
+ // locks in lexical order, which can help us to avoid dead locks.
+ // Now if first thread acquires lock on hdfs, 2nd thread wait for lock
+ // on hdfs, and first thread acquires lock on ozone. Once after first
+ // thread releases user locks, 2nd thread acquires them.
+
+ int compare = newUserResource.compareTo(oldUserResource);
+ String temp;
+
+ // Order the user names in sorted order. Swap them.
+ if (compare > 0) {
+ temp = newUserResource;
+ newUserResource = oldUserResource;
+ oldUserResource = temp;
+ }
+
+ if (compare == 0) {
+ // both users are equal.
+ manager.lock(oldUserResource);
+ } else {
+ manager.lock(newUserResource);
+ try {
+ manager.lock(oldUserResource);
+ } catch (Exception ex) {
+ // We got an exception acquiring 2nd user lock. Release already
+ // acquired user lock, and throw exception to the user.
+ manager.unlock(newUserResource);
+ throw ex;
+ }
+ }
+ lockSet.set(resource.setLock(lockSet.get()));
+ }
+ }
+
+
+
+ /**
+ * Acquire lock on multiple users.
Review comment:
Nit: Comment should read "release", you can fix it while committing.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 266294)
Time Spent: 4h 10m (was: 4h)
> Create new OzoneManagerLock class
> ---------------------------------
>
> Key: HDDS-1723
> URL: https://issues.apache.org/jira/browse/HDDS-1723
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Components: Ozone Manager
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
> Labels: pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> This Jira is to use bit manipulation, instead of hashmap in OzoneManager lock
> logic. And also this Jira follows the locking order based on the document
> attached to HDDS-1672 jira.
> This Jira is created based on [~anu] comment during review of HDDS-1672.
> 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 lock
> 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 super
> efficient. [@nandakumar131|https://github.com/nandakumar131] . But as I said
> let us not do that in this patch.
>
> This Jira will add new class, integration of this new class into code will be
> done in a new jira.
> Clean up of old code also will be done in new jira.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
