[
https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479494
]
Yonik Seeley commented on SOLR-182:
-----------------------------------
> But what is the failure mode?
Any number of modes of failure.... it's very tough to predict them (I think
you'd have to be Doug Lea :-)
1)
thread #1 does map.put("/path/to/handler", handler)
thread #2 iterates over the map and gets a ConcurrentModificationException
2)
thread #1 does map.put("/path/to/handler", handler)
thread #2 does map.put("/path/to/handler2", handler2)
a) If they hash to the same bucket, one could overwrite the other
b) one or both could cause resize() to be invoked... ouch! many different
modes of failure there
3)
thread #1 does map.put("/path/to/handler", handler) causing resize to be
called()
thread #2 does a map.get("/myexistinghandler") and it gets back null
I'd agree with you if the only mode of failure was to get back null for the
current object being put in the map (since it's a race between threads anyway,
null is a valid view - one should synchronize externally in that case anyway).
But, any insert can mess up all other reads.
> 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
>
>
> 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.
