-
Notifications
You must be signed in to change notification settings - Fork 79
Use Opaque for locking instead of byte[], improve reuse of base64 keys #154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
kohlschuetter
wants to merge
21
commits into
dCache:master
Choose a base branch
from
kohlschuetter:ck/Inode2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
28fcfe4
core: Allow reuse of "Opaque" file id key
kohlschuetter e0176ff
core: Reduce fileId byte[] usage; improve and encourage use of Opaque
kohlschuetter bcb3e17
core: Prepare AbstractLockManager for Opaque support
kohlschuetter 7334be2
core: Make SimpleLm use AbstractLockManager2
kohlschuetter d3a5bce
dlm: Make DistributedLockManager use AbstractLockManager2
kohlschuetter e1bcf35
core: test: Switch SimpleLmTest to use Opaque instead of byte[] keys
kohlschuetter f22dba3
dlm: test: Switch DistributedLockManagerTest to use Opaque
kohlschuetter 72b87c9
core: NFS4Client: Use Opaque.forBytes
kohlschuetter 52f8de7
core, dlm: Remove deprecated LockManager methods
kohlschuetter a957861
core: Opaque: remove deprecated methods
kohlschuetter da8f898
core: Inode: Provide helper method create Inode from Opaque fileIdKey
kohlschuetter 957551f
core: Opaque: Convert to interface, remove Serializable
kohlschuetter e74c087
core, dlm: Opaque: rename methods to properly indicate conversion step
kohlschuetter b52ab01
core: Opaque: provide helper method to instantiate from ByteBuffer
kohlschuetter 7a64663
core: Opaque: Add javadoc to forBytes method
kohlschuetter ff66e69
core: Opaque: Remove position offset from ByteBuffer constructor
kohlschuetter d53f432
core: Opaque: Clarify behavior of equals/hashCode
kohlschuetter d1bc72d
core: Opaque: Remove unnecessary "public" from "public static"
kohlschuetter 8f4c511
core: Opaque: Improve reuse of file id data for PseudoFS innerInode
kohlschuetter 3ad63db
core: Inode: Improve forFileIdKey and innerInode
kohlschuetter 09e8063
core: PseudoFS: Properly resolve the inner root inode
kohlschuetter File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks the
symmetry
requirements:if
x.equals(y)
, theny.equals(x)
. Thus,o
must be an instanceofOpaqueImpl
.https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#equals(java.lang.Object)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow.
This is the
equals
implementation forOpaqueImpl
, so we know that about our own object.We should be able to have "equals" be true for all implementations of
Opaque
(see line96
)Then we special-case where both objects are
OpaqueImpl
-- here we can compare the two arrays directly without cloning (lines100-101
)Lastly (line
102
), we compareOpaqueImpl
against any otherOpaque
implementation. Here we know thattoBytes
gives us the array to compare.Other implementations of
Opaque
must behave the same way (i.e., first checkinstanceof Opaque
, bail if not, then potentially optimize).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the points above: My goal is to have an environment where an
Inode
is theOpaque
file id key.That works once PseudoFS is out of the equation. (my custom
VirtualFileSystem
will return customInode
subclasses that implementOpaque
).Since this may or may not be the default scenario for nfs4j, to keep the current Inode/file-id separation, we need a standard implementation (
OpaqueImpl
). However, hashCode and equals should ignore the specific implementation details because in the end only the bytes transferred from an NFS client matter (we don't want false-negative matches)