[
https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483879
]
Ryan McKinley commented on SOLR-182:
------------------------------------
> - For lazy loading, you don't even want to load the class if it's not used
> (loaded classes take up
> resources, and there may be optional jars that will cause errors).
Ok - I'm a little nervous about that because I like things to fail loudly at
startup rather then wait to tell you they were configured incorrectly.
(SOLR-179) But if you are using lazy loading, that is probably the behavior
you would expect.
I'll change it so that the LazyRequestHandlerWrapper stores the string value
for the class name rather then the Class itself.
>
> - it really seems like init() must be called before any calls to
> handleRequest.
>
yes, init() must be called before any call to handleRequest() - absolutely
Correct me if I have the lifecycle wrong, but I think it is ok:
1. SolrDispatchFilter.init() calls SolrCore.getSolrCore()
2. SolrCore.getSolrCore() calls SolrCore constructor
3. SolrCore constructor initalizes schema, listeners, index and writers
4. then calls reqHandlers.initHandlersFromConfig( SolrConfig.config )
this function:
a. creates each handler for solrconfig.xml and registers it
b. calls init() on each handler - (since register was called first, each
handler knows what else exists, but it may or may not be initialized)
5. initialize searcher / updateHandler
6. SolrDispatchFilter.init() finishes and solr starts accepting requests.
All handlers call init() before they could possibly receive any requests. No
requests can hit solr during the limbo period (a-b), It is only in the
"unstable" state in the SolrCore constructor - I think the benefits of handlers
knowing what else is registered during their init() method is worth the
slightly awkward construction.
The public interface:
SolrCore.register( String handlerName, SolrRequestHandler handler )
assumes that the handler is properly initialized. As soon as this is called it
can immediately start accepting requests. I will make the javadoc more clear
on this point.
The only potentially dangerous function is (4) initHandlersFromConfig. This is
a package private function that defiantly should not be called anywhere else.
Calling this function twice is not normal, if someone does it, they are asking
for trouble.
> register SolrRequestHandlers at runtime / lazy loading
> ------------------------------------------------------
>
> Key: SOLR-182
> URL: https://issues.apache.org/jira/browse/SOLR-182
> Project: Solr
> Issue Type: Improvement
> Reporter: Ryan McKinley
> Fix For: 1.2
>
> Attachments: SOLR-182-RuntimeRequestHandlers.patch,
> SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch,
> SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch
>
>
> It would be useful to be able to register handlers after SolrCore has been
> initialized initialized. It is also useful to be able to ask what handlers
> are registered and to where. This patch adds the following functions to
> SolrCore:
> SolrRequestHandler registerRequestHandler(String handlerName,
> SolrRequestHandler handler);
> Collection<SolrRequestHandler> getRequestHandlers(Class<? extends
> SolrRequestHandler> clazz);
> It also guarantees that request handlers will be initialized with an argument
> saying what path it is registered to. RequestHandlerBase gets a bean for the
> registered path.
> While discussing this, Yonik suggested making it possible to defer
> initialization of some handlers that will be infrequently used. I added the
> 'LazyRequestHandlerWrapper' (if taking this out makes the patch any easier
> to commit - it can get its own issue)
> check:
> http://www.nabble.com/Dynamic-RequestHandler-loading-tf3351707.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
