lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <yo...@apache.org>
Subject Re: Dynamic RequestHandler loading
Date Mon, 05 Mar 2007 21:43:40 GMT
On 3/5/07, Ryan McKinley <ryantxu@gmail.com> wrote:
> I know I'm pushing solr to do things it was never designed to do, so
> shut me up quick if this is not where you want things to go - I could
> quietly implement this with quick hacks, but i'd rather not...
>
> Currently SolrCore loads all the request handlers in a final variable
> as the instance is initialized:
>
> private final RequestHandlers reqHandlers = new
> RequestHandlers(SolrConfig.config);
>
> This is a little strange because forces the request handlers to be
> loaded as the instance is initialized - not in a more appropriate
> place like after initWriters() in the constructor.  The bad side
> affects to this are that handlers can not know about the schema or
> config directory in the init() method.  They are forced to do some
> sort of lazy loading.
>
> The other thing I would like is to be able to dynamically register
> handlers.  For example, i have one handler that wants to register 6
> related handlers (each one maps a different action - it only makes
> sense to have them as a collection).  While i could put six entries in
> solrconfig, this will quickly become unruly.
>
> How do you feel about:
>
> 1. move the request handler initialization into the constructor after
> initWriters()?
>
> 2. Exposing the following functions in SolrCore:
>
>  // this already exists
>   SolrRequestHandler getRequestHandler(String handlerName);
>
>  // this will register the handler and return whatever used to be at
> that path (or null)
>   SolrRequestHandler registerRequestHandler(String handlerName,
> SolrRequestHandler )
>
>  // get all the registered handlers by class
>   Collection<SolrRequestHandler> getRequestHandlers( Class<? extends,
> SolrRequestHandler> clazz );

By class?  What's that for?

Everything else seems to make sense... it would mean an extra
synchronization per Solr request, but that shouldn't be measurable
given everything else we are doing.

One thing we lost going from individual servlets to a filter was the
potential for load-on-demand handlers.  If/when CSV and SQL update
handlers get put in the core, it might be nice if they weren't loaded
at startup.

-Yonik

Mime
View raw message