[ https://issues.apache.org/jira/browse/SOLR-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605812#comment-15605812 ]
ASF subversion and git services commented on SOLR-9536: ------------------------------------------------------- Commit c1d1e6098a6c4dcc2d6f031b1299545f79972794 in lucene-solr's branch refs/heads/branch_6x from markrmiller [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1d1e60 ] SOLR-9536: Add hossman to CHANGES. > 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 > Assignee: Mark Miller > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org