[jira] [Comment Edited] (SOLR-9536) OldBackupDirectory timestamp init bug causes NPEs from SnapShooter?
[
https://issues.apache.org/jira/browse/SOLR-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505410#comment-15505410
]
Hrishikesh Gadre edited comment on SOLR-9536 at 9/20/16 3:01 AM:
-
[~hossman] Yes this is correct. We initialize the timestamp field during the
construction. I have prepared a patch and running the unit tests currently.
Will submit the patch in next couple of hours.
was (Author: hgadre):
[~ hossman] Yes this is correct. We initialize the timestamp field during the
construction. I have prepared a patch and running the unit tests currently.
Will submit the patch in next couple of hours.
> 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}}, there is no guarantee that the
> {{Optional}} instance is itself non-null...
> {code}
>private Optional 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 {{commit}} -- 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
[jira] [Comment Edited] (SOLR-9536) OldBackupDirectory timestamp init bug causes NPEs from SnapShooter?
[
https://issues.apache.org/jira/browse/SOLR-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505410#comment-15505410
]
Hrishikesh Gadre edited comment on SOLR-9536 at 9/20/16 3:01 AM:
-
[~hossman] Yes this is correct. We need to initialize the timestamp field
during the construction. I have prepared a patch and running the unit tests
currently. Will submit the patch in next couple of hours.
was (Author: hgadre):
[~hossman] Yes this is correct. We initialize the timestamp field during the
construction. I have prepared a patch and running the unit tests currently.
Will submit the patch in next couple of hours.
> 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}}, there is no guarantee that the
> {{Optional}} instance is itself non-null...
> {code}
>private Optional 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 {{commit}} -- 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
[jira] [Comment Edited] (SOLR-9536) OldBackupDirectory timestamp init bug causes NPEs from SnapShooter?
[
https://issues.apache.org/jira/browse/SOLR-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505410#comment-15505410
]
Hrishikesh Gadre edited comment on SOLR-9536 at 9/20/16 3:01 AM:
-
[~ hossman] Yes this is correct. We initialize the timestamp field during the
construction. I have prepared a patch and running the unit tests currently.
Will submit the patch in next couple of hours.
was (Author: hgadre):
[~hoss...@fucit.org] Yes this is correct. We initialize the timestamp field
during the construction. I have prepared a patch and running the unit tests
currently. Will submit the patch in next couple of hours.
> 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}}, there is no guarantee that the
> {{Optional}} instance is itself non-null...
> {code}
>private Optional 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 {{commit}} -- 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
