-
Notifications
You must be signed in to change notification settings - Fork 127
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
Batch fix sonarqube failures #1930
Conversation
@yegor256 please reveiw |
* This includes call of {@link ThreadLocal#remove()} method to prevent | ||
* memory leaks. | ||
*/ | ||
public static void cleanUp() { |
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.
@mximp I don't see anyone calling this method. I think, remove()
is supposed to be called right after we use TERMS
, not in a separate method. But I'm not sure...
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.
@yegor256 You are right - the method is not called by anyone. The thing is I cannot define the moment "right after TERM is used". It's static and holds the value which is required throughout the program execution. So I see correct place for remove
to be called before program exits. But that doesn't make sense.
So in this case I just created fake
method according to SonarQube expectations.
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 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.
@yegor256 From this post it is still not clear how to apply in our case. According to Java Docs:
Removes the current thread's value for this thread-local variable. If this thread-local variable is subsequently read by the current thread, its value will be reinitialized by invoking its initialValue() method, unless its value is set by the current thread in the interim. This may result in multiple invocations of the initialValue method in the current thread.
Which means that if we call this method on TERM
it will be reset, i.e. cache of the vertexes will be cleared. Which is not what we want. It would make sense if we have clear lifecycle of a thread.. But "end-of-thread"/"end-of-processing" is not identifiable in our case.
PR Summary
|
@yegor256 please check my comment #1930 (comment) |
@yegor256 reminder |
@rultor merge |
@mximp @yegor256 Oops, I failed. You can see the full log here (spent 2hr)
|
TldrThis PR introduces some improvements, fixes and code refactorings for the eo-maven-plugin and eo-parser. Detailed summary
|
@yegor256 please try again |
@rultor merge |
@mximp @yegor256 We failed, sorry, try again:
|
@yegor256 please merge |
@rultor merge |
#1897 Fixes of SonarCloud findings.
Add puzzles for the rest.