[
https://issues.apache.org/jira/browse/HDDS-1723?focusedWorklogId=265957&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265957
]
ASF GitHub Bot logged work on HDDS-1723:
----------------------------------------
Author: ASF GitHub Bot
Created on: 24/Jun/19 18:43
Start Date: 24/Jun/19 18:43
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_r296858071
##########
File path:
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/lock/OzoneManagerLock.java
##########
@@ -0,0 +1,312 @@
+/**
+ * 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 ((lockSetVal & value.setMask) == value.setMask) {
+ currentLocks.add(value.name);
+ }
+ }
+ 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 {
+ int compare = newUserResource.compareTo(oldUserResource);
Review comment:
If you do a simple swap or create two string variables, you can eliminate a
whole if ..else blocks and avoid repeating the locking code.
----------------------------------------------------------------
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:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 265957)
Time Spent: 1h 40m (was: 1.5h)
> 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: 1h 40m
> 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: [email protected]
For additional commands, e-mail: [email protected]
