Hoss Man created SOLR-9536:
------------------------------
Summary: OldBackupDirectory timestamp init bug causes NPEs from
SnapShooter?
Key: SOLR-9536
URL: https://issues.apache.org/jira/browse/SOLR-9536
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
On IRC, a 6.2.0 user reported getting an NPE from SnapShooter.deleteOldBackups
L244, with the only other frame of the stacktrace being
{{lambda$createSnapAsync$1}} L196 (it was a screenshot, not text easily
cut/paste here)
The problematic L244 is...
{code}
if (obd.getTimestamp().isPresent()) {
{code}
..and i believe the root of the issue is that while {{getTimestamp()}} is
declared to return an {{Optional<Date>}}, there is no guarantee that the
{{Optional}} instance is itself non-null...
{code}
private Optional<Date> timestamp;
public OldBackupDirectory(URI basePath, String dirName) {
this.dirName = Preconditions.checkNotNull(dirName);
this.basePath = Preconditions.checkNotNull(basePath);
Matcher m = dirNamePattern.matcher(dirName);
if (m.find()) {
try {
this.timestamp = Optional.of(new SimpleDateFormat(SnapShooter.DATE_FMT,
Locale.ROOT).parse(m.group(1)));
} catch (ParseException e) {
this.timestamp = Optional.empty();
}
}
}
{code}
Allthough i'm not 100% certain, I believe the way the user was triggering this
bug was by configuring classic replication configured with something like
{{<str name="replicateAfter">commit</str>}} -- so that usage may be neccessary
to trigger the exception?
Alternatively: perhaps this exception gets logged the *first* time anyone tries
to use any code that involves SnapShooter -- and after that a timestamp file
*is* created and teh problem neer manifests itself again?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
