kfaraz commented on code in PR #16887:
URL: https://github.com/apache/druid/pull/16887#discussion_r1721216375


##########
services/src/main/java/org/apache/druid/cli/CliPeon.java:
##########
@@ -205,7 +223,67 @@ public void configure(Properties properties)
   protected List<? extends Module> getModules()
   {
     return ImmutableList.of(
-        new DruidProcessingModule(),
+        Modules.override(new DruidProcessingModule()).with(
+            new Module()
+            {
+              @Override
+              public void configure(Binder binder)
+              {
+
+              }
+
+              @Provides
+              @ManageLifecycle
+              public QueryProcessingPool getProcessingExecutorPool(
+                  Task task,
+                  DruidProcessingConfig config,
+                  ExecutorServiceMonitor executorServiceMonitor,
+                  Lifecycle lifecycle
+              )
+              {
+                if (!task.supportsQueries()) {
+                  return new ForwardingQueryProcessingPool(Execs.dummy());
+                }
+                return new MetricsEmittingQueryProcessingPool(
+                    PrioritizedExecutorService.create(
+                        lifecycle,
+                        config
+                    ),
+                    executorServiceMonitor
+                );

Review Comment:
   > I didn't understand this part. Why should we not be using the 
ForwardingQueryProcessingPool. The benefit of my approach would be that the 
calling code wouldn't need to assume that the processing pool can be null 
anywhere, and handle that case separately. Moreover, it also acts as a 
safeguard in case any non querying task tries to submit a task to the pool, 
instead of complacently executing the task in the same thread (as with the 
direct processing pool).
   
   I meant that if we know upfront that this task is not meant to use the query 
processing pool, then we should _never_ return an instance that can be used at 
all, even if it causes the task to fail (since it was doing something illegal 
anyway).
   
   I agree with your point about `null`.
   How about we add a `NoopQueryProcessingPool` that throws `Unsupported` 
exception when anything is submitted to it?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to