-
Notifications
You must be signed in to change notification settings - Fork 9.2k
HADOOP-18675: Fix CachedSASToken noisy log errors when SAS token has YYYY-MM-DD expiration #5508
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
Conversation
|
🎊 +1 overall
This message was automatically generated. |
steveloughran
left a comment
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.
makes sense. added some comments. I'm also going to reinstate the bit from the PR template which asks the submitter which storage endpoint they used.
see testing azure
| // set first time and ensure reference equality | ||
| cachedSasToken.update(token); | ||
| String cachedToken = cachedSasToken.get(); | ||
| Assert.assertTrue(token == cachedToken); |
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.
assertEquals(expected, actual) or AssertJ.asserThat(). 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.
was following the existing tests which seem to want to assert reference equality a lot, I will change it for the new test.
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.
yeah, old code...just because it was done that way doesn't mean we should carry on
| } | ||
| } catch (DateTimeParseException dateOnlyException) { | ||
| // log original exception | ||
| LOG.error("Error parsing se query parameter ({}) from SAS as ISO_DATE_TIME or ISO_DATE.", seValue, dateTimeException); |
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.
now, if there's a problem here it is still going to log a lot, isn't it?
might be best to use a LogExactlyOnce log here for the error line, and log at debug the rest of the time
| } | ||
|
|
||
| @Test | ||
| public void testValidExpirationParsing() { |
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 there a test for an invalid date time parsing now?
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's an existing one testing invalid se=abc in testUpdateAndGetWithInvalidToken. I'll add another method specifically for invalid expiration.
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
| } else { | ||
| throw dateTimeException; | ||
| } | ||
| } catch (DateTimeParseException dateOnlyException) { |
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 have something like:
private static final DateTimeFormatter[] formatters;
private OffsetDateTime getParsedDateTime(String dateTime) {
for(DateTimeFormatter formatter : formatters) {
try {
TemporalAccessor temporalAccessor = formatter.parseBest(dateTime);
if(temporalAccessor instanceof OffsetDateTime) {
return (OffsetDateTime) temporalAccessor;
}
if(temporalAccessor instanceof LocalDateTime) {
return ((LocalDateTime) temporalAccessor).atOffset(ZoneOffset.UTC);
}
} catch (DateTimeParseException e) {
}
}
return null;
}
And from this method we will just call seDate = getParsedDateTime(seValue);
This way I feel we can prevent nested code.
|
We're closing this stale PR because it has been open for 100 days with no activity. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
Description of PR
When using SAS tokens with expiration dates in the format YYYY-MM-DD, a frequent error appears in the logs. The cause is that the code expects ISO_DATE_TIME, but ISO_DATE type formats are acceptable as well.
How was this patch tested?
Added tests that the expiration is properly parsed using the previous failing format.
Ran
mvn test -Dtest="TestCachedSASToken"For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?