[
https://issues.apache.org/jira/browse/SOLR-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137667#comment-14137667
]
Hoss Man commented on SOLR-6519:
--------------------------------
another seed, full stack...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=CoreMergeIndexesAdminHandlerTest
-Dtests.method=testMergeIndexesCoreAdminHandler -Dtests.seed=CD7BE4551EE0F637
-Dtests.slow=true -Dtests.locale=zh_SG -Dtests.timezone=Asia/Calcutta
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.05s |
CoreMergeIndexesAdminHandlerTest.testMergeIndexesCoreAdminHandler <<<
[junit4] > Throwable #1: org.apache.solr.common.SolrException: SolrCore
'collection1' is not available due to init failure: Unrecognized lockType:
single
[junit4] > at
__randomizedtesting.SeedInfo.seed([CD7BE4551EE0F637:8111B29C08B928C]:0)
[junit4] > at
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:745)
[junit4] > at
org.apache.solr.handler.admin.CoreMergeIndexesAdminHandlerTest.testMergeIndexesCoreAdminHandler(CoreMergeIndexesAdminHandlerTest.java:81)
[junit4] > at java.lang.Thread.run(Thread.java:745)
[junit4] > Caused by: org.apache.solr.common.SolrException: Unrecognized
lockType: single
[junit4] > at
org.apache.solr.core.SolrCore.<init>(SolrCore.java:889)
[junit4] > at
org.apache.solr.core.SolrCore.<init>(SolrCore.java:651)
[junit4] > at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
[junit4] > at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
[junit4] > at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
[junit4] > at
java.util.concurrent.FutureTask.run(FutureTask.java:262)
[junit4] > at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[junit4] > at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[junit4] > ... 1 more
[junit4] > Caused by: org.apache.solr.common.SolrException: Unrecognized
lockType: single
[junit4] > at
org.apache.solr.core.StandardDirectoryFactory.createLockFactory(StandardDirectoryFactory.java:73)
[junit4] > at
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:350)
[junit4] > at
org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:275)
[junit4] > at
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:487)
[junit4] > at
org.apache.solr.core.SolrCore.<init>(SolrCore.java:793)
[junit4] > ... 8 more
{noformat}
> In trunk change Solr's DirectoryFactory.create method to take LockFactory
> -------------------------------------------------------------------------
>
> Key: SOLR-6519
> URL: https://issues.apache.org/jira/browse/SOLR-6519
> Project: Solr
> Issue Type: Bug
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0
>
> Attachments: SOLR-6519.patch, SOLR-6519.patch
>
>
> Because of NIO2 changes and the corresponding workaround, it is impossible
> now to create a Directory and "hope" that the lock factory directory is not
> created. Especially if you want some non-standard lock factory, this blows up.
> The problem is: The lock dir is now created in ctor. As workaround I made all
> factories set NoLockFactory initially through ctor (see SOLR-6518), but this
> is just a workaround for incorrect API design.
> In fact the main problem is just stupid: Why does protected
> CachingDirectoryFactory.create() not take the lock factory? I think its
> because of backwards compatibility, but with Solr 5.0 we can change this.
> In future we want to make the lock factory non-mutable in Directory, so this
> is an important change. In addition, injectLockFactory looks horrible, this
> code is a häckidy-hick-hack!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
