[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700806#action_12700806
]
Kay Kay commented on SOLR-1106:
-------------------------------
{quote}
Any Core can get access to the CoreContainer (via
core.getCoreDescriptor().getCoreContainer()) and all of the SolrCores it is
managing, so couldn't these new hooks you need be implented in regular
RequestHandler?
I ask this from the "how to achieve a niche goal with the minimal number of
invasive changes" standpoint -- mainly because i don't really understand what
new types of "monitoring hooks" you're thinking of. if they seem like something
that would be generally useful to lots of people, why not add them to
CoreAdminHandler? if they *pattern* of adding them seems like something that
will come up for lots of people *then* i would worry about making
CoreAdminHandler more extensible.
{quote}
Monitoring hooks was one of the examples that we are using internally . If at
the end of the implementation I find it generic enough - I would definitely be
more than happy to share the patch for that too - but this I need this to be a
building block on which other similar components could be built.
Another context in which we need this is w.r.t doing some matching analysis
between different indices (managed via - a multi-core instance) where the
indices are managed by the respective SolrCore's UpdateHandlers while a req /
response via http would goto a place that has access to both the cores and
return the result,
RequestHandler does not seem logically correct (though is indirectly possible
via the method outlined earlier ) since that would bind the request Handler to
one of the cores while the behavior intended is across cores - hence that needs
to be done a level above all the cores and I selected admin Handler since that
seems to be the only handler used in solr.xml .
But what could be useful is to retain the requestHandler and make them
configurable in solr.xml to address similar requests in the future.
> Pluggable CoreAdminHandler (Action ) architecture that allows for custom
> handler access to CoreContainer / request-response
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-1106
> URL: https://issues.apache.org/jira/browse/SOLR-1106
> Project: Solr
> Issue Type: New Feature
> Environment: Java 5, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently there are certain default actions implemented in CoreAdminHandler (
> CREATE , SWAP, RELOAD , ALIAS etc.) .
> For the purpose of in-house monitoring tools that needs to interact with
> multiple cores at a given solr instance - we need custom handlers that has
> access to CoreContainer and the req, resp of the same.
> So - the proposed way of injecting handlers is as follows.
> In solr.xml - we add a new schema -
> <solr >
> <cores adminPath="/cores/admin">
>
> <adminActionHandler action="newaction"
> handlerType="com.mydomain.myclass" />
> </cores>
> </solr>
> New abstract class - CoreAdminActionRequestHandler added - that
> com.mydomain.myclass would need to inherit from.
> Following action handlers registered by default -
> registerCustomAdminHandler("create", new
> AdminCreateActionRequestHandler());
> registerCustomAdminHandler("rename", new
> AdminRenameActionRequestHandler());
> registerCustomAdminHandler("alias", new AdminAliasActionRequestHandler());
> registerCustomAdminHandler("unload", new
> AdminUnloadActionRequestHandler());
> registerCustomAdminHandler("status", new
> AdminStatusActionRequestHandler());
> registerCustomAdminHandler("persist", new
> AdminPersistActionRequestHandler());
> registerCustomAdminHandler("reload", new
> AdminReloadActionRequestHandler());
> registerCustomAdminHandler("swap", new AdminSwapActionRequestHandler());
> Trying to register a handler with one that already exists would result in an
> error ( Hence - the above mentioned defaults would not be overridden).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
