-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Avoid logging duplicate deprecation warnings multiple times #1660
Avoid logging duplicate deprecation warnings multiple times #1660
Conversation
Can one of the admins verify this patch? |
✅ Gradle Wrapper Validation success 8d1d07698203277c19fc559b54245cce4314daa2 |
✅ Gradle Precommit success 8d1d07698203277c19fc559b54245cce4314daa2 |
❌ Gradle Check failure 8d1d07698203277c19fc559b54245cce4314daa2 |
8d1d076
to
47a5366
Compare
✅ Gradle Wrapper Validation success 47a5366924836114d948056537e37093e9684dcd |
✅ Gradle Precommit success 47a5366924836114d948056537e37093e9684dcd |
❌ Gradle Check failure 47a5366924836114d948056537e37093e9684dcd |
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.
Nice work. I would appreciate another pair of eyes other than myself. Maybe @andrross?
if (keys.contains(this.keyWithXOpaqueId)) { | ||
return true; | ||
} | ||
keys.add(this.keyWithXOpaqueId); |
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.
Is this safe on an unsynchronized HashSet? I'm assuming this method can be accessed concurrently from any number of threads. It's likely fine for the de-duplication logic to be best effort and a duplicate log entry emitted due to a race is not a big deal, but I'm more concerned about undefined behavior now or in future JDK versions if the underlying data structure is modified in the middle of a contains()
invocation.
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.
Definitely agree! We can use the SynchronizedSet, the only downside might be performance since the collection will be locked by a single thread at a time. If that is not a concern, we can make this synchronized. WDYT?
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 think ConcurrentHashMap will give the concurrency guarantees while also allowing lock-free reads. Something like:
private final Set<String> keys = ConcurrentHashMap.newKeySet();
...
public boolean isAlreadyLogged() {
return !keys.add(keyWithXOpaqueId);
}
Under the hood it looks like the KeySetView of ConcurrentHashMap is using the same method as putIfAbsent
in its add
method. That should be lock-free in the case that the key is present, and only incur any synchronization overhead in the case that it is newly adding a key.
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.
Sorry for the delay! That makes sense. I have updated the implementation to use the keySet() from ConcurrentHashMap.
test/framework/src/main/java/org/opensearch/test/rest/OpenSearchRestTestCase.java
Outdated
Show resolved
Hide resolved
start gradle check |
❌ Gradle Check failure 47a5366924836114d948056537e37093e9684dcd |
Signed-off-by: Vacha <vachshah@amazon.com>
Signed-off-by: Vacha <vachshah@amazon.com>
Signed-off-by: Vacha <vachshah@amazon.com>
47a5366
to
931bb72
Compare
❌ Gradle Check failure 931bb72d6bac52526117977513ac38c475fea8bb |
This should resolve after PR #1731 is merged. |
931bb72
to
998f97c
Compare
❌ Gradle Check failure 998f97c1eda48c805231bf3e52483f680e3e3e11 |
* Otherwise, a warning can be logged by some test and the upcoming test can be impacted by it. | ||
*/ | ||
public static void resetDeprecatedMessageForTests() { | ||
keys = new HashSet<>(); |
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 isn't right because you're resetting the field to the non-concurrent hashset implementation. I would actually replace this with keys.clear()
since the ConcurrentHashMap is thread safe.
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.
Oh my bad! I missed this, I will change it.
private static Set<String> keys = ConcurrentHashMap.newKeySet(); | ||
private String keyWithXOpaqueId; |
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.
Both of these can be final (see comment below about a change to the reset method).
@@ -19,10 +19,10 @@ | |||
- skip: | |||
version: " - 6.2.99" | |||
reason: deprecated in 6.3 | |||
features: "warnings" | |||
features: "allowed_warnings" |
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 admit that I don't really understand what these files mean, but why did you change "warnings" to "allowed_warnings"?
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.
allowed_warnings
asserts if the warning occurs but does not fail the test if it doesn't. This is in a lot of files and there is no order in which they run so it is very difficult to determine when the first warning will occur given that a lot of tests assert the same duplicate warnings.
Signed-off-by: Vacha Shah <vachshah@amazon.com>
998f97c
to
2330282
Compare
Nice job @VachaShah and thanks for a thorough code review @andrross! |
* Avoid logging duplicate deprecation warnings multiple times Signed-off-by: Vacha <vachshah@amazon.com> * Fixes test failures Signed-off-by: Vacha <vachshah@amazon.com> * Adding deprecation logger tests Signed-off-by: Vacha <vachshah@amazon.com> * Using ConcurrentHashMap keySet Signed-off-by: Vacha Shah <vachshah@amazon.com> (cherry picked from commit e66ea2c)
…times (#2315) * Avoid logging duplicate deprecation warnings multiple times (#1660) * Avoid logging duplicate deprecation warnings multiple times Signed-off-by: Vacha <vachshah@amazon.com> * Fixes test failures Signed-off-by: Vacha <vachshah@amazon.com> * Adding deprecation logger tests Signed-off-by: Vacha <vachshah@amazon.com> * Using ConcurrentHashMap keySet Signed-off-by: Vacha Shah <vachshah@amazon.com> (cherry picked from commit e66ea2c) * Fixing failing RestResizeHandlerTests in 1.x Signed-off-by: Vacha Shah <vachshah@amazon.com> Co-authored-by: Vacha <vachshah@amazon.com>
Description
This PR adds logic to avoid logging duplicate deprecation messages. It resolves the issue #1108 and all other deprecation message instances. (Coming from #1537 (review)). There are also test changes since a lot of tests verify the deprecation warnings.
Issues Resolved
Closes #1108
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.