[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616825#comment-13616825
]
Mark Miller commented on SOLR-4652:
-----------------------------------
The crux of the issue is that solr.xml was never able to specify stuff like
this before - so the entire design is still basically what we had when Solr was
single core.
As far as I remember, shard handler started in solrconfig.xml and was per core.
At some point, someone moved it to core container so that things like the
thread pool could be shared across cores. At this point, we lost the ability to
configure it - support was simply removed.
Much later, I needed to set some timeouts for freebsd blackhole reasons and I
found I had no way to do this - so I shoved the shardhandler into solr.xml
simply so I could set these timeouts in tests. This is why you couldn't even
change the impl - it was all just falling debris.
At least, if I remember the sequence of events correctly.
Now that shard handler is in solr.xml and properly supported, it only seems
likely that further things will move to solr.xml that belong at the core
container level, and so +1 to coming up with a design that makes all this work
as it should.
> Resource loader has broken behavior for solr.xml plugins (basically
> ShardHandlerFactory)
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-4652
> URL: https://issues.apache.org/jira/browse/SOLR-4652
> Project: Solr
> Issue Type: Bug
> Reporter: Ryan Ernst
>
> I have the following scenario:
> MyShardHandlerFactory is plugged in via solr.xml. The jar containing
> MyShardHandlerFactory is in the shared lib dir. There are a couple issues:
> 1. From within a per core handler (that is loaded within the core's lib dir),
> you grab the ShardHandlerFactory from CoreContainer, casting to
> MyShardHandlerFactory will results in a ClassCastException with a message
> like "cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory".
> 2. Adding a custom dir for shared lib (for example "mylib") does not work.
> The ShardHandlerFactory is initialized before sharedLib is loaded.
> 3. I believe there is another problem with the chaining, in that if you
> specified a sharedLib with the same name as the default, then you get one
> classloader that is used to instantiate, but then if you try to instantiate
> an instance of that class from within core specific code, like a handler, you
> will get the intermediate sharedLib based class loader to load a different
> version (libLoader in CoreContainer).
> I've been pouring through the code on this and I don't see an easy fix. I'll
> keep looking at it, but I wanted to get this up so hopefully others have some
> thoughts on how best to fix. IMO, it seems like there needs to be a clear
> chain of resource loaders (one for loading solr.xml, a child for loading the
> lib dir, used for solr.xml plugins, a grandchild for per core config, and a
> great grandchild for per core lib dir based plugins). Right now there are
> some siblings, because any place a SolrResourceLoader is created with a null
> parent classloader, it gets the jetty thread's classloader as the parent.
--
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]
