lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley" <>
Subject Re: Dynamic RequestHandler loading
Date Mon, 05 Mar 2007 22:14:49 GMT
> >
> >  // get all the registered handlers by class
> >   Collection<SolrRequestHandler> getRequestHandlers( Class<? extends,
> > SolrRequestHandler> clazz );
> By class?  What's that for?

It was useful to check what else is configured.  The alternative is to have a
  Collection<SolrRequestHandler> getRequestHandlers() and have let the
client sort out what is what.  In the case I am looking at, I want to
check if a handler of given type is already registered - if not, i
register one.

getRequestHandlers() would be equivolent to:
getRequestHandlers( SolrRequestHandler.class )

We will need some way to ask what is registered without knowing the
path it is registered to.

> 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.

would access to getRequestHandler( name ) need to be synchronized?

Are there any real problems if not?  I don't imagine much would change
after startup.

> 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.

perhaps we could add:
 <requestHandler name="..." class=".." statup="lazy" />

Then we could have a LazyRequestHandlerWrapper that only hangs on to
configuration parameters, but done not initialize the delegate handler
until its first request.  This would be transparent to the
Filter/Servlet framework

But I'll save that for another day :)

View raw message