-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
HADOOP-18851. Performance improvement for DelegationTokenSecretManager #6803
Conversation
@ChenSammi , Can you review the changes and provide your input ? Thanks. |
💔 -1 overall
This message was automatically generated. |
...n/java/org/apache/hadoop/security/token/delegation/AbstractDelegationTokenSecretManager.java
Outdated
Show resolved
Hide resolved
...n/java/org/apache/hadoop/security/token/delegation/AbstractDelegationTokenSecretManager.java
Outdated
Show resolved
Hide resolved
...n/java/org/apache/hadoop/security/token/delegation/AbstractDelegationTokenSecretManager.java
Outdated
Show resolved
Hide resolved
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
running = true; | ||
tokenRemoverThread = new Daemon(new ExpiredTokenRemover()); | ||
tokenRemoverThread.start(); | ||
}finally { |
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.
There need be a blank between "}" and finally. Kindly check other "finally" statements too.
Also please check the checkstyle issues reported by the CI, https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6803/2/artifact/out/results-checkstyle-hadoop-common-project_hadoop-common.txt.
Hi @vikaskr22 @ChenSammi Thanks for your works here. One nit concerns, #6001 try to remove synchronization then revert and add RWLock here, any issues do you meet while remove synchronization? Thanks. |
Hi @Hexiaoqiao , technically I didn't see or observe any issues till now but @ChenSammi has some concerns related to concurrency in other sub classes of AbstractDelegationTokenSecretManager.java . I had done testing with RangerKMS and there ZKDelegationTokenSecretManager.java is used as implementing class. That means, our test suite only verifies ZK specific cases. There are other implementation that is for HDFS federation, YARN etc. I @ChenSammi point is, as part of last commit, I removed "synchronization" from super class and took care of concurrency in ZK sub class. So I was breaking concurrency at API level and all the implementing classes needs to take care of that. and at the same time, I don't have test suite internally that verifies anything except Ranger KMS DT usage. One more point she raised that, what about any other subclass outside this repo? They might have written their code in assumption that lock has been acquired at API level. Although I went through the source code of other implementing classes, and for me it still seems good. But due to lack of automated test suite and concurrency nature, I agreed to implement using Lock API. Using ReadWriteLock API, at least I am able to unblock multiple reader threads, like verifyToken(). Now verifyToken() can be invoked by multiple threads due to ReadLock nature. And write lock will ensure thread safety at API level. @ChenSammi , Please add your input as well in case I missed anything. Thanks. |
Yes, removing the synchronized directly have potential risks to sub classes of AbstractDelegationTokenSecretManager. Using LOCK is a safe way to replace synchronized and can improve the concurrency too. That's the motivation of this implementation. @Hexiaoqiao . |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@Hexiaoqiao , @ChenSammi , Anything else needed from my side? I had fixed all the review comments that's part of my commit. |
@ChenSammi Got it. Make sense to me.
@vikaskr22 The current changes LGTM. One nit comment about |
@Hexiaoqiao , the mvnsite failure is, looks like not relevant, but other merged MR seems doesn't have this failure.
|
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
Hi @ChenSammi, @vikaskr22 |
💔 -1 overall
This message was automatically generated. |
@Hexiaoqiao , thanks for the info about mvnsite. Currently, hadoop-yetus is passed. This "Apache Yetus", I never see it's all green. Should this github CI be all green before the PR can be committed? |
💔 -1 overall
This message was automatically generated. |
Thanks @vikaskr22 for the contribution, and @Hexiaoqiao for the review. |
Description of PR
AbstractDelegationTokenSecretManager's method all synchronized and are blocking each other, even multiple readers threads are blocking each other. This PR is an efforts towards optimising the synchronization contexts.
For detailed description, please go through the discussion on https://issues.apache.org/jira/browse/HADOOP-18851
Latest review I received where I was suggested not to remove synchronization entirely instead address the threads blocking issue using Lock API. This approach will help avoid any unknown concurrency issues.
How was this patch tested?
Build is working fine. And this is more about a logical change like where to acquire or release a lock. It requires careful review. There is not any functional logic change.
For code changes:
LICENSE
,LICENSE-binary
,NOTICE-binary
files?