hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Work logged] (HDDS-1672) Improve locking in OzoneManager
Date Wed, 26 Jun 2019 00:58:00 GMT

     [ https://issues.apache.org/jira/browse/HDDS-1672?focusedWorklogId=267159&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-267159
]

ASF GitHub Bot logged work on HDDS-1672:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 26/Jun/19 00:57
            Start Date: 26/Jun/19 00:57
    Worklog Time Spent: 10m 
      Work Description: hadoop-yetus commented on issue #949: HDDS-1672. Improve locking in
OzoneManager.
URL: https://github.com/apache/hadoop/pull/949#issuecomment-505675480
 
 
   :broken_heart: **-1 overall**
   
   
   
   
   
   
   | Vote | Subsystem | Runtime | Comment |
   |:----:|----------:|--------:|:--------|
   | 0 | reexec | 31 | Docker mode activated. |
   ||| _ Prechecks _ |
   | +1 | dupname | 1 | No case conflicting files found. |
   | +1 | @author | 0 | The patch does not contain any @author tags. |
   | +1 | test4tests | 0 | The patch appears to include 2 new or modified test files. |
   ||| _ trunk Compile Tests _ |
   | 0 | mvndep | 66 | Maven dependency ordering for branch |
   | +1 | mvninstall | 468 | trunk passed |
   | +1 | compile | 264 | trunk passed |
   | +1 | checkstyle | 73 | trunk passed |
   | +1 | mvnsite | 0 | trunk passed |
   | +1 | shadedclient | 870 | branch has no errors when building and testing our client artifacts.
|
   | +1 | javadoc | 161 | trunk passed |
   | 0 | spotbugs | 311 | Used deprecated FindBugs config; considering switching to SpotBugs.
|
   | +1 | findbugs | 499 | trunk passed |
   ||| _ Patch Compile Tests _ |
   | 0 | mvndep | 34 | Maven dependency ordering for patch |
   | +1 | mvninstall | 435 | the patch passed |
   | +1 | compile | 283 | the patch passed |
   | +1 | javac | 283 | the patch passed |
   | -0 | checkstyle | 54 | hadoop-ozone: The patch generated 31 new + 0 unchanged - 0 fixed
= 31 total (was 0) |
   | +1 | mvnsite | 0 | the patch passed |
   | +1 | whitespace | 0 | The patch has no whitespace issues. |
   | +1 | shadedclient | 677 | patch has no errors when building and testing our client artifacts.
|
   | +1 | javadoc | 156 | the patch passed |
   | +1 | findbugs | 510 | the patch passed |
   ||| _ Other Tests _ |
   | +1 | unit | 242 | hadoop-hdds in the patch passed. |
   | -1 | unit | 1372 | hadoop-ozone in the patch failed. |
   | +1 | asflicense | 36 | The patch does not generate ASF License warnings. |
   | | | 6445 | |
   
   
   | Reason | Tests |
   |-------:|:------|
   | Failed junit tests | hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis |
   |   | hadoop.ozone.TestStorageContainerManager |
   |   | hadoop.ozone.client.rpc.TestSecureOzoneRpcClient |
   |   | hadoop.ozone.client.rpc.TestOzoneRpcClient |
   |   | hadoop.ozone.client.rpc.TestOzoneAtRestEncryption |
   |   | hadoop.hdds.scm.pipeline.TestSCMPipelineManager |
   
   
   | Subsystem | Report/Notes |
   |----------:|:-------------|
   | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-949/9/artifact/out/Dockerfile
|
   | GITHUB PR | https://github.com/apache/hadoop/pull/949 |
   | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient
findbugs checkstyle |
   | uname | Linux 8e8c151f73df 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux |
   | Build tool | maven |
   | Personality | personality/hadoop.sh |
   | git revision | trunk / 4b50981 |
   | Default Java | 1.8.0_212 |
   | checkstyle | https://builds.apache.org/job/hadoop-multibranch/job/PR-949/9/artifact/out/diff-checkstyle-hadoop-ozone.txt
|
   | unit | https://builds.apache.org/job/hadoop-multibranch/job/PR-949/9/artifact/out/patch-unit-hadoop-ozone.txt
|
   |  Test Results | https://builds.apache.org/job/hadoop-multibranch/job/PR-949/9/testReport/
|
   | Max. process+thread count | 4879 (vs. ulimit of 5500) |
   | modules | C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/ozone-manager U: . |
   | Console output | https://builds.apache.org/job/hadoop-multibranch/job/PR-949/9/console
|
   | versions | git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1 |
   | Powered by | Apache Yetus 0.10.0 http://yetus.apache.org |
   
   
   This message was automatically generated.
   
   
 
----------------------------------------------------------------
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:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 267159)
    Time Spent: 7h 50m  (was: 7h 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: 7h 50m
>  Remaining Estimate: 0h
>
> In this Jira, we shall follow the new lock ordering. In this way, in volume requests
we can solve the issue of acquire/release/reacquire problem. And few bugs in the current
implementation of S3Bucket/Volume operations.
>  
> Currently after acquiring volume lock, we cannot acquire user lock. 
> This is causing an issue in Volume request implementation, acquire/release/reacquire
volume lock.
>  
> Case of Delete Volume Request: 
>  # Acquire volume lock.
>  # Get Volume Info from DB
>  # Release Volume lock. (We are releasing the lock, because while acquiring 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
>  
> We can avoid this acquire/release/reacquire lock issue by making volume lock as low weight. 
>  
> 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 owner lock
>  # release volume lock. 
> Same issue is seen with SetOwner for Volume request also.
> During HDDS-1620 [~arp] brought up this issue. 
> I am proposing the above solution to solve this issue. Any other idea/suggestions 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


Mime
View raw message