[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586182#comment-13586182
]
Hoss Man commented on SOLR-4373:
--------------------------------
Alex:
I just noticed something in one of your earlier comments...
bq. I am unable to get the problem go away by using coreLoadThreads="1": <cores
adminPath="/admin/cores" coreLoadThreads="1">
...the "coreLoadThreads" option should be on the {{<solr/>}} element, not the
{{<cores/>}} element, can you please test that again?
Other comments..
bq. Is there something I can do to help troubleshooting this? I haven't tried
working with Solr source yet, but I am a Java developer and can dig around if
there is some sort of information at where library references are stored.
primarily we build up a ClassLoader per SolrCore in SOlrResourceLoader, each of
which hangs off of the parent classloader for the webapp -- but the use of SPI
in lucene complicates things in ways i still don't fully understand.
bq. Isn't that for SPIs only? Does that cover TokenFactories
Yes, many of the various factories in Solr are handled using SPI now (take a
look at SolrResourceLoader.reloadLuceneSPI())
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
> Affects Versions: 4.1
> Reporter: Alexandre Rafalovitch
> Priority: Blocker
> Labels: lib, multicore
> Fix For: 4.2, 5.0, 4.1.1
>
> Attachments: multicore-bug.zip
>
>
> Having lib directives in solrconfig.xml seem to wipe out/override the
> definitions in previous cores.
> The exception (for the earlier core) is:
> at
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
> at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:369)
> at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:113)
> at
> org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1000)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1033)
> at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:629)
> at org.apache.solr.core.CoreContainer$3.call(CoreContainer.java:624)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.solr.common.SolrException: Plugin init failure for
> [schema.xml] analyzer/filter: Error loading class
> 'solr.ICUFoldingFilterFactory'
> at
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:177)
> at
> org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:377)
> at
> org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:95)
> at
> org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:43)
> at
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)
> The full replication case is attached.
> If the SECOND core is turned off in solr.xml, the FIRST core loads just fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
