You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Artem Abeleshev (Jira)" <ji...@apache.org> on 2023/02/17 10:25:00 UTC
[jira] [Comment Edited] (SOLR-16282) Improve custom actions support of CoreAdminHandler
[ https://issues.apache.org/jira/browse/SOLR-16282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690324#comment-17690324 ]
Artem Abeleshev edited comment on SOLR-16282 at 2/17/23 10:24 AM:
------------------------------------------------------------------
I've described the motivation factors of this issue in the [PR 931|[https://github.com/apache/solr/pull/931]] Here is a quote of the part of the description:
??At the moment implementing custom actions for {{CoreAdminHandler}} implies subsclassing of the {{CoreAdminHandler}} and overriding {{handleCustomAction}} method. This has numerous problems. First, it seems a bit too much for the simple concept of implementing custom actions and quite quirky (out of the way Solr usually do things). The second thing is, current custom actions implementation is just a block of code to be called, so it is not integrated into the standard actions workflow and doesn't use async facility. Third, it has the following problem: let's say, one developer created {{CoreAdminHandler}} with action {{{}A{}}}, and another developer created {{CoreAdminHandler}} with action {{{}B{}}}. If the user want to use both actions {{A}} and {{B}} user will get a problem, as user can override only one handler, i.e no handler "chaining" is supported.??
was (Author: abeleshev):
I've described the motivation factors of this issue in the [PR 931|[https://github.com/apache/solr/pull/931].] Here is a quote of the part of the description:
??At the moment implementing custom actions for {{CoreAdminHandler}} implies subsclassing of the {{CoreAdminHandler}} and overriding {{handleCustomAction}} method. This has numerous problems. First, it seems a bit too much for the simple concept of implementing custom actions and quite quirky (out of the way Solr usually do things). The second thing is, current custom actions implementation is just a block of code to be called, so it is not integrated into the standard actions workflow and doesn't use async facility. Third, it has the following problem: let's say, one developer created {{CoreAdminHandler}} with action {{{}A{}}}, and another developer created {{CoreAdminHandler}} with action {{{}B{}}}. If the user want to use both actions {{A}} and {{B}} user will get a problem, as user can override only one handler, i.e no handler "chaining" is supported.??
> Improve custom actions support of CoreAdminHandler
> --------------------------------------------------
>
> Key: SOLR-16282
> URL: https://issues.apache.org/jira/browse/SOLR-16282
> Project: Solr
> Issue Type: Improvement
> Affects Versions: main (10.0)
> Reporter: Artem Abeleshev
> Assignee: Christine Poerschke
> Priority: Minor
> Fix For: 9.1, main (10.0)
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Original _CoreAdminHandler_ ({_}org.apache.solr.handler.admin.CoreAdminHandler{_}) has a support of custom actions by providing _handleCustomAction_ method. It is intended for users who want to implement an additional actions (for example, for some instumental or statistical purposes). By default _handleCustomAction_ method throws an exception implying user should subclass handler and provide its own _handleCustomAction_ method implementation. But there are some structural problems.
> If we check how the _CoreAdminHandler_ triggers the _handleCustomAction_ method we will see that it is always runs in a _sync_ way. Despite the fact that _CoreAdminHandler_ has nice support of running the actions in an _async_ way. Moreover, if user push the custom action request with an _async_ parameter it will create _TaskObject_ object and will place it to the tracking map occupying one slot and will never clean it up:
> _org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(SolrQueryRequest, SolrQueryResponse)_
> {code:java}
> @Override
> public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throws Exception {
> ...
> final String taskId = req.getParams().get(CommonAdminParams.ASYNC);
> final TaskObject taskObject = new TaskObject(taskId);
> if (taskId != null) {
> ...
> addTask(RUNNING, taskObject);
> }
> final String action = req.getParams().get(ACTION, STATUS.toString()).toLowerCase(Locale.ROOT);
> CoreAdminOperation op = opMap.get(action);
> if (op == null) {
> handleCustomAction(req, rsp);
> return;
> }
>
> final CallInfo callInfo = new CallInfo(this, req, rsp, op);
> ...
> if (taskId == null) {
> callInfo.call();
> } else {
> try {
> ...
> parallelExecutor.execute(
> () -> {
> boolean exceptionCaught = false;
> try {
> callInfo.call();
> taskObject.setRspObject(callInfo.rsp);
> taskObject.setOperationRspObject(callInfo.rsp);
> } catch (Exception e) {
> exceptionCaught = true;
> taskObject.setRspObjectFromException(e);
> } finally {
> removeTask("running", taskObject.taskId);
> if (exceptionCaught) {
> addTask("failed", taskObject, true);
> } else {
> addTask("completed", taskObject, true);
> }
> }
> });
> } finally {
> ...
> }
> }
> ...
> } {code}
> As we can see, the call to the _handleRequestBody_ is just a call to the custom block of the code that is not weaved nicely to the overall worflow. I suggest to update the logic to not just call custom block of the code, but instead to force it to provide a _CoreAdminOp_ instance, that would be used in the further execution as a regular operation extracterd from the {_}opMap{_}. Like this:
>
> {code:java}
> ...
> final String action = req.getParams().get(ACTION, STATUS.toString()).toLowerCase(Locale.ROOT);
> CoreAdminOp op = opMap.get(action);
> if (op == null) {
> op = getCustomOperation(action);
> }
> ...
> {code}
>
> This way the custom actions can be easily integrated in the general worflow with minimal efforts. In result we will get:
> - support of an async custom actions
> - using of the standard _CoreAdminOp_ and _CallInfo_ structures
> - more clean code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org