[SOLR-16282] Improve custom actions support of CoreAdminHandler

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: main (10.0)
• Fix Version/s: 9.1, main (10.0)
• Assignee: Christine Poerschke
• Reporter: Artem Abeleshev
• Created: 04/Jul/22 05:43
• Updated: 21/Feb/23 15:50
• Resolved: 15/Aug/22 16:32

Description

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)

  @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 {
          ...
        }
      }
      ...
  } 

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:

 

      ...
      final String action = req.getParams().get(ACTION, STATUS.toString()).toLowerCase(Locale.ROOT);
      CoreAdminOp op = opMap.get(action);
      if (op == null) {
        op = getCustomOperation(action);
      }
      ...

 

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

Issue Links

• links to: GitHub Pull Request #931