[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877708#comment-16877708
]
Mikhail Khludnev edited comment on SOLR-13587 at 7/3/19 10:39 AM:
------------------------------------------------------------------
I suppose we need to go with it, enforce closing backup repoes. Need to think
how to enforce it across tests.
Here's why: HdfsBackupRepo should FS.newInstance and then it should supply it
for HDFSDirectories, and close afterward. Otherwise, it either will open (HD)FS
on the every file (that's expected to be slow) or accidentally hit FS already
closed like in SOLR-9961.
Concerns, opinions?
was (Author: mkhludnev):
I suppose we need to go with it, enforce closing backup repoes. Need to think
how to enforce it across tests.
Here's why: HdfsBackupRepo should FS.newInstance and then it should supply it
for HDFSDirectories, and close afterward. Otherwise, it either will open (HD)FS
on the every file (that's expected to be slow) or accidentally hit FS already
closed.
Concerns, opinions?
> Close BackupRepository after every usage
> ----------------------------------------
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
> Affects Versions: 8.1
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
