Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

XuPengfei-1020
Copy link
Member

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.

@@ -343,7 +343,7 @@ public Set<InternalNode> getNodes(NodeState state)
}

@Override
public synchronized Set<InternalNode> getActiveCatalogNodes(CatalogHandle catalogHandle)
public Set<InternalNode> getActiveCatalogNodes(CatalogHandle catalogHandle)
Copy link
Member

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 

Copy link
Member Author

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'.

@findepi
Copy link
Member

findepi commented Dec 29, 2023

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.
@XuPengfei-1020
Copy link
Member Author

Under what circumstances does this change make a difference?

These methods with lock are simple enough, so remove the lock on it wont make a big difference of performance.
But it logically does not need a lock on it to keep the executor against each other while called.

@dain
Copy link
Member

dain commented Jan 25, 2024

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.

@XuPengfei-1020
Copy link
Member Author

Thinks for your reply, I aggre with what you said.
Actually, the locks caused some performance in trino clusters of our team but which has made some changes relating
withNodeManager module.
I closed this pr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants