lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <>
Subject [jira] [Commented] (SOLR-7073) Add an API to add a jar to a collection's classpath
Date Thu, 05 Mar 2015 18:24:38 GMT


Noble Paul commented on SOLR-7073:

Thanks for the comments

bq.I don't like that delete-runtimelib has just the name and not a json body. In future if
we want to delete old versions of jars, 

There is one an only one version of a given jar that you can add to a collection. So, you
can either delete or update

bq.Minor typos in JarRepository - s/decerease/decrease and s/getSytemCollReplica/getSystemCollReplica.


bq.We should check for liveness as well inside getSystemCollReplica


bq.RecoveryStrategy has some code commented out. Is it not necessary anymore?

We no more have those Lazy Wrappers . What we have is {{LazyPluginHolder}} . When you do a
{{get()}} for a plugin, you get a live instance. fully instantiated

 bq.The patch removes the disableExternalLib flag from RequestHandlers. Is that not needed
That is moved to {{PluginRegistry}} where it assumes a new name {{enable.runtime.lib}}

bq.Can we please rename SolrConfig.clsVsInfo to classVsInfo? and LazyRHHolder to LazyRequestHandlerHolder?


bq.Why is LazyRHHolder required? 

It was required because of the feature we released in 5.0 for a per request handler classloader.
I'm going to remove that

bq.RequestHandlers.initHandlersFromConfig used to call init on the handlers. I can't find
where they are being initialized now. 

It all goes into {{PluginsRegistry}} . Initialization is done inside there

> Add an API to add a jar to a collection's classpath
> ---------------------------------------------------
>                 Key: SOLR-7073
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>         Attachments: SOLR-7073.patch, SOLR-7073.patch, SOLR-7073.patch
> The idea of having separate classloaders for each component may be counter productive.
 This aims to add a jar dependency to the collection itself and each core belonging to that
collection will have the jar in the classpath
> As we load everything from the .system collection , we cannot make the core loading delayed
till .system is fully loaded and is available . 
> There is a new  set of  config commands to manage the dependencies on a collection level.
It is possible to have more than one jar as a dependency. The "lib" attribute is same as the
blob name that we use in the blob store API
> example:
> {code}
> curl http://localhost:8983/solr/collection1/config -H 'Content-type:application/json'
 -d '{
> "add-runtimelib" : {"name": "jarname" , "version":2 },
> "update-runtimelib" :{"name": "jarname" ,"version":3},
> "delete-runtimelib" :"jarname" 
> }' 
> {code}
> The same is added to the overlay.json .
> The default SolrResourceLoader does not have visibility to  these jars . There is a classloader
that can access these jars which is made available only to those components which are specially
> Every pluggable component can have an optional extra attribute called {{runtimeLib=true}},
which means, these components are not be loaded at core load time. They are tried to be loaded
on demand and if all the dependency jars are not available at the component load time an error
is thrown . 
> example of registering a valueSourceParser which depends on the runtime classloader
> {code}
> curl http://localhost:8983/solr/collection1/config -H 'Content-type:application/json'
 -d '{
> "create-valuesourceparser" : {"name": "nvl" ,
> "runtimeLib": true, 
> "class":" , 
> "nvlFloatValue":0.0 }  
> }'
> {code} 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message