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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org