You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2014/09/15 02:47:34 UTC
[jira] [Updated] (SOLR-6518) CachingDirectoryFactory subclasses
must init directory with NoLockFactory, because the real lock factory gets
set later via injectLockFactory
[ https://issues.apache.org/jira/browse/SOLR-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated SOLR-6518:
--------------------------------
Attachment: SOLR-6518.patch
Patch. I will commit this now, because the bug prevents tests from succeeding.
We should really work on a better solution (pass the lock factory to protected create method, so it can be set with ctor).
> CachingDirectoryFactory subclasses must init directory with NoLockFactory, because the real lock factory gets set later via injectLockFactory
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6518
> URL: https://issues.apache.org/jira/browse/SOLR-6518
> Project: Solr
> Issue Type: Bug
> Affects Versions: 5.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0
>
> Attachments: SOLR-6518.patch
>
>
> The whole setup should really be changed in Solr trunk, especially as we want to make the lockfactory non-mutable (set via directory ctor).
> As workaround to prevent SimpleFSLockFactory from creating the lock directory initially, we should pass NoLockFactory in the create method. This is possible because injectLockFactory will set the "configured one" afterwards.
> This change is needed in trunk, because the LockFactory creates the directory in its ctor, which leads to problems with NIO2.
> In addition, the SlrCore.newSolrDataDir does not cleanup and close the directory correctly if an error occurs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org