[ 
https://issues.apache.org/jira/browse/SOLR-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505491#comment-15505491
 ] 

ASF GitHub Bot commented on SOLR-9536:
--------------------------------------

GitHub user hgadre opened a pull request:

    https://github.com/apache/lucene-solr/pull/81

    [SOLR-9536] Initialize timestamp field with Optional.empty() to avoid an NPE

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/hgadre/lucene-solr SOLR-9536_fix

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/lucene-solr/pull/81.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #81
    
----
commit b3f52a7d4dd4823c2ba2e54ae75dc0f50533dcf8
Author: Hrishikesh Gadre <hga...@cloudera.com>
Date:   2016-09-20T02:58:21Z

    [SOLR-9536] Initialize timestamp field with Optional.empty() to avoid an NPE

----


> 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: Varun Thacker
>
> 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

Reply via email to