Hoss Man created SOLR-9536:

             Summary: OldBackupDirectory timestamp init bug causes NPEs from 
                 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...
  if (obd.getTimestamp().isPresent()) {
..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...

   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, 
      } catch (ParseException e) {
        this.timestamp = Optional.empty();

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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to