Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.4.0
-
Done
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 Arpit Agarwal 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.
Attachments
Attachments
Issue Links
1.
|
Use generation of resourceName for locks in OzoneManagerLock |
|
Resolved | Bharat Viswanadham |
|
||||||||
2.
|
Create new OzoneManagerLock class |
|
Resolved | Bharat Viswanadham |
|
