[
https://issues.apache.org/jira/browse/HDDS-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Viswanadham updated HDDS-1672:
-------------------------------------
Description:
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.
was:
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.
> Improve locking in OzoneManager
> -------------------------------
>
> Key: HDDS-1672
> URL: https://issues.apache.org/jira/browse/HDDS-1672
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Components: Ozone Manager
> Affects Versions: 0.4.0
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> 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: [email protected]
For additional commands, e-mail: [email protected]
