-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Remove unnecessary locks on DiscoveryNodeManager #19843
Conversation
e842af5
to
1a3f5b0
Compare
1a3f5b0
to
0ab403e
Compare
@@ -343,7 +343,7 @@ public Set<InternalNode> getNodes(NodeState state) | |||
} | |||
|
|||
@Override | |||
public synchronized Set<InternalNode> getActiveCatalogNodes(CatalogHandle catalogHandle) | |||
public Set<InternalNode> getActiveCatalogNodes(CatalogHandle catalogHandle) |
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.
Reasonably configured intellij will now produce a warning
Access to field 'activeNodesByCatalogHandle' outside of declared guards
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.
Fixed, remove the @GuardedBy('this') modifier on the field 'activeNodesByCatalogHandle'.
Under what circumstances does this change make a difference? |
Threads which try to 'getAllNode' or 'getActiveConnectorNodes' could be against with thread that are refreshing workers state. This control of race condition seems unnecessary, so removing locks may be improve performance slightly.
These methods with lock are simple enough, so remove the lock on it wont make a big difference of performance. |
If this doesn't affect anything then the only reason to change this code would be that the change makes the code easier to maintain. Looking at the change, I think the new code will be more difficult to maintain as it requires reading all uses to understand the relationship between the fields. Therefore, I'd leave this code alone. |
Thinks for your reply, I aggre with what you said. |
Description
Threads which try to 'getAllNode' or 'getActiveConnectorNodes' could be against with thread that are refreshing workers state. This control of race condition seems unnecessary, so removing locks may be improve performance slightly.
Additional context and related issues
No related issues so far.
Release notes
( ) This is not user-visible or is docs only, and no release notes are required.