-
Notifications
You must be signed in to change notification settings - Fork 36
Fix log messages and init progress for the profile API #374
Fix log messages and init progress for the profile API #374
Conversation
Codecov Report
@@ Coverage Diff @@
## master #374 +/- ##
============================================
- Coverage 78.95% 78.94% -0.01%
Complexity 2655 2655
============================================
Files 247 247
Lines 11719 11723 +4
Branches 1009 1009
============================================
+ Hits 9253 9255 +2
- Misses 1991 1993 +2
Partials 475 475
Flags with carried forward coverage won't be shown. Click here to find out more.
|
String.format("%.0f%%", percent), | ||
// Without Locale.US, sometimes conversions use localized decimal digits | ||
// rather than the usual ASCII digits. See https://tinyurl.com/y5sdr5tp | ||
String.format(Locale.US, "%.0f%%", percent), |
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.
Can we change other places for String.format
? I see such warning in build log
2021-01-26T23:00:07.9472702Z Forbidden method invocation: java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default locale]
2021-01-26T23:00:07.9475976Z in com.amazon.opendistroforelasticsearch.ad.transport.AnomalyResultTransportAction (AnomalyResultTransportAction.java:1063)
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.
added missing locales in src/main
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.
Do we need such Locale.US
for other places of String.format()
?
If only specifying Locale.US
here, but nowhere else, can we get expected percentage string in US Locale?
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.
Do we need such Locale.US for other places of String.format()?
Using String.format without locale is a forbidden pattern by ES. Apparently it is bad.
If only specifying Locale.US here, but nowhere else, can we get expected percentage string in US Locale?
Yes.
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.
Using String.format without locale is a forbidden pattern by ES. Apparently it is bad.
Is there any documentation regarding why it is forbidden? want to learn more about it. In this case, I guess we should have a utility static method called StringFormat()
, which is a wrapper of String.format(Locale.US, "", "")
, so that we should only use the wrapper method StringFormat
in this repo.
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 guess you have already found the one in another conversation. For all forbidden APIs, check https://github.com/policeman-tools/forbidden-apis
There are too many cases like this. We cannot create a wrapper for all of them. I enabled locale check for string.format. build will fail if people forget about it.
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.
sounds good to me.
3fd39a1
to
4ad4706
Compare
@@ -511,7 +512,7 @@ public void getFeaturesForSampledPeriods( | |||
ActionListener<Optional<Entry<double[][], Integer>>> listener | |||
) { | |||
Map<Long, double[]> cache = new HashMap<>(); | |||
logger.info(String.format("Getting features for detector %s ending at %d", detector.getDetectorId(), endTime)); | |||
logger.info(String.format(Locale.US, "Getting features for detector %s ending at %d", detector.getDetectorId(), endTime)); |
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.
No much experience on Locale
. Checked other plugin, looks they are using Locale.ROOT
https://github.com/opendistro-for-elasticsearch/alerting/blob/master/core/src/main/kotlin/com/amazon/opendistroforelasticsearch/alerting/core/resthandler/RestScheduledJobStatsHandler.kt#L81
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.
From java doc:
The root locale is the locale whose language, country, and variant are empty ("") strings. This is regarded as the base locale of all locales, and is used as the language/country neutral locale for the locale sensitive operations.
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 used as the language/country neutral locale
I think ROOT is a safer solution, but I am ok with either of US/ROOT/ENGLISH option. Feel free to use one of them.
Passing a specific locale here helps in most cases. If you are writing a GUI in English language, pass Locale.ENGLISH everywhere, otherwise text output of numbers or dates may not match the language of your GUI! If you want Formatter to behave in a invariant way, use Locale.ROOT, too (then it will for sure format numbers with period and no comma for thousands, just like Float.toString(float) does).
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 have no strong preference on either. Tested Locale.US fixes the init progress error. Locale.ROOT should work too.
I tested using 3 locales. They sure have differences.
jshell> System.out.println(DateFormat.getDateInstance(DateFormat.SHORT, Locale.US).format(new Date()));
1/28/21
jshell> System.out.println(DateFormat.getDateInstance(DateFormat.SHORT, Locale.ROOT).format(new Date()));
2021-01-28
jshell> System.out.println(DateFormat.getDateInstance(DateFormat.SHORT, Locale.ENGLISH).format(new Date()));
1/28/21
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.
Hmmm, looks Locale.ROOT is also friendly to user in countries other than US. Let's use ROOT then. Thanks.
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.
Replaced US with ROOT.
This PR fixes incorrect or unnecessary log messages. The PR also specifies init progress to use ASCII explicitly. Otherwise, it is possible we may get unexpected characters. Testing done: 1. gradle build
5201c71
to
bb09144
Compare
* Fix log messages and init progress for the profile API This PR fixes incorrect or unnecessary log messages. The PR also specifies init progress to use ASCII explicitly. Otherwise, it is possible we may get unexpected characters. Testing done: 1. gradle build
Issue #, if available:
Description of changes:
This PR fixes incorrect or unnecessary log messages. The PR also uses ASCII to convert the init progress to a string. Otherwise, we may get unexpected characters.
Testing done:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.