Replace Processing ExecutorService with QueryProcessingPool by abhishekagarwal87 · Pull Request #11382 · apache/druid

abhishekagarwal87 · 2021-06-24T06:11:02Z

Description

This PR refactors the code for QueryRunnerFactory#mergeRunners to accept a new interface called QueryProcessingPool instead of ExecutorService for concurrent execution of query runners. This interface will let custom extensions inject their own implementation for deciding which query-runner to prioritize first. The default implementation is the same as today that takes the priority of query into account. QueryProcessingPool can also be used as a regular executor service. It has a dedicated method for accepting query execution work so implementations can differentiate between regular async tasks and query execution tasks. This dedicated method also passes the QueryRunner object as part of the task information. This hook will let custom extensions carry any state from QuerySegmentWalker to QueryProcessingPool#mergeRunners which is not possible currently.

Key changed/added classes in this PR

QueryProcessingPool
QueryRunnerFactory
ForwardingQueryProcessingPool
DirectQueryProcessingPool
PrioritizedQueryRunnerCallable
AbstractPrioritizedQueryRunnerCallable

This PR has:

been self-reviewed.
added documentation for new or modified features or behaviors.
added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
added or updated version, license, or notice information in licenses.yaml
added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.

rohangarg · 2021-06-24T15:38:21Z

+  /**
+   * @return - Returns this pool as an executor service that can be used for other asynchronous operations.
+   */
+  ListeningExecutorService asExecutorService();


I think this method leaks the internals of the interface. For instance, some caller may call this method and then pass the executor in other parts of code unintentionally. Also, if someone has to implement a QueryProcessingPool which is composite and contains multiple pools inside it, it would become hard to implement this interface.
Would it be better to rather have the original ExecutorService as is, and then inject that executor service to the DefaultProcessingPool? The ExecutorService interface is richer and common. QueryProcessingPool can be used in cases where a PrioritizedQueryRunnerCallable submission is needed.

something like this?

@ExtensionPoint public interface QueryProcessingPool extends ListeningExecutorService { /** * Submits the query execution unit task for asynchronous execution. * * @param task - Task to be submitted. * @param <T> - Task result type * @param <V> - Query runner sequence type * @return - Future object for tracking the task completion. */ <T, V> ListenableFuture<T> submitQueryExecution(PrioritizedQueryRunnerCallable<T, V> task); }

Yes, I was thinking like the snippet you mentioned above. (probably the interface can be called something like QueryRunnerProcessingPool since it only allows submit for QueryRunners currently - the submitQueryExecution can also become submit).
If this interface looks ok, then the DefaultProcessingPool's constructor signature can be : DefaultProcessingPool(@Processing ExecutorService)

I assume you want to make QueryProcessingPool compatible with ExecutorService because of ConcurrentGrouper?

Just clarifying my stance here, @rohangarg's idea sounds good to me, but I don't have strong preference here.

Sounds good. I do want to keep the method separate though. Either that or PrioritizedQueryRunnerCallable<T, V> task should not extend Callable. My reasoning is that then Implementations don't have to do instance of checks for differentiating between query execution tasks and other async tasks.

Yes

I assume you want to make QueryProcessingPool compatible with ExecutorService because of ConcurrentGrouper?

@rohangarg @jon-wei @jihoonson What do you think?

LGTM
maybe the naming could be more generic since this would be used in both ingestion and querying layer both.

On real-time nodes too, the pool is used in query execution.

jihoonson · 2021-06-24T17:00:58Z

-public @interface Processing
+public interface PrioritizedQueryRunnerCallable<T, V> extends PrioritizedCallable<T>
 {
+  QueryRunner<V> getRunner();


How will this method be used? I only see it used in a test in this PR.

This method can be used by the extensions to get the runner that the given query execution task corresponds to. That in turn can be used to fetch any state associated with the QueryRunner such as the segment info for example.

I see. Can you add it in the javadoc of this method?

sure thing.

jihoonson · 2021-06-25T16:13:58Z

-public @interface Processing
+public interface PrioritizedQueryRunnerCallable<T, V> extends PrioritizedCallable<T>
 {
+  QueryRunner<V> getRunner();


I see. Can you add it in the javadoc of this method?

jon-wei · 2021-06-25T22:17:44Z

+package org.apache.druid.query;

 /**
+ * An implementation of {@link PrioritizedCallable} that also let's caller get access to associated {@link QueryRunner}


Suggested change

* An implementation of {@link PrioritizedCallable} that also let's caller get access to associated {@link QueryRunner}

* An implementation of {@link PrioritizedCallable} that also lets caller get access to associated {@link QueryRunner}

jihoonson · 2021-06-25T16:24:22Z

+ * @param <T>
+ * @param <V>


Can you please complete the javadoc for the parameters?

done in next patch.

jihoonson · 2021-06-25T18:22:23Z

+  /**
+   * @return - Returns this pool as an executor service that can be used for other asynchronous operations.
+   */
+  ListeningExecutorService asExecutorService();


I assume you want to make QueryProcessingPool compatible with ExecutorService because of ConcurrentGrouper?

jihoonson

I reviewed only the design of new interfaces, QueryProcessingPool and PrioritizedQueryRunnerCallable. Their design LGTM.

jon-wei · 2021-06-25T22:17:44Z

+package org.apache.druid.query;

 /**
+ * An implementation of {@link PrioritizedCallable} that also let's caller get access to associated {@link QueryRunner}


Suggested change

* An implementation of {@link PrioritizedCallable} that also let's caller get access to associated {@link QueryRunner}

* An implementation of {@link PrioritizedCallable} that also lets caller get access to associated {@link QueryRunner}

jon-wei · 2021-06-25T22:35:15Z

+  /**
+   * @return - Returns this pool as an executor service that can be used for other asynchronous operations.
+   */
+  ListeningExecutorService asExecutorService();


I think making the processing a pool a kind of executor service makes sense, let's go with that if you agree

…1382) This PR refactors the code for QueryRunnerFactory#mergeRunners to accept a new interface called QueryProcessingPool instead of ExecutorService for concurrent execution of query runners. This interface will let custom extensions inject their own implementation for deciding which query-runner to prioritize first. The default implementation is the same as today that takes the priority of query into account. QueryProcessingPool can also be used as a regular executor service. It has a dedicated method for accepting query execution work so implementations can differentiate between regular async tasks and query execution tasks. This dedicated method also passes the QueryRunner object as part of the task information. This hook will let custom extensions carry any state from QuerySegmentWalker to QueryProcessingPool#mergeRunners which is not possible currently.

abhishekagarwal87 added Area - Querying Refactoring labels Jun 24, 2021

Replace Processing ExecutorService with QueryProcessingPool

9440e79

abhishekagarwal87 force-pushed the query-processing-pool branch from aa9be88 to 9440e79 Compare June 24, 2021 06:13

Add test for code coverage

7e22f00

abhishekagarwal87 added the Design Review label Jun 24, 2021

rohangarg reviewed Jun 24, 2021

View reviewed changes

jihoonson added the Release Notes label Jun 24, 2021

jihoonson reviewed Jun 24, 2021

View reviewed changes

jihoonson reviewed Jun 25, 2021

View reviewed changes

jihoonson approved these changes Jun 25, 2021

View reviewed changes

jon-wei reviewed Jun 25, 2021

View reviewed changes

abhishekagarwal87 added 5 commits June 28, 2021 11:37

Fix javadoc

4702aae

Make QueryProcessingPool extend ListeningExecutorService

9802e7c

checkstyle fix

b76c20c

Add tests for MetricsEmittingQueryProcessingPool

fb7d1b5

Putting class at the right place

3cb1b99

jon-wei approved these changes Jun 30, 2021

View reviewed changes

rohangarg approved these changes Jul 1, 2021

View reviewed changes

abhishekagarwal87 merged commit 03a6a6d into apache:master Jul 1, 2021

abhishekagarwal87 deleted the query-processing-pool branch July 22, 2021 10:13

clintropolis added this to the 0.22.0 milestone Aug 12, 2021

clintropolis mentioned this pull request Sep 3, 2021

[Draft] 0.22.0 Release Notes #11657

Closed

	* An implementation of {@link PrioritizedCallable} that also let's caller get access to associated {@link QueryRunner}
	* An implementation of {@link PrioritizedCallable} that also lets caller get access to associated {@link QueryRunner}

Conversation

abhishekagarwal87 commented Jun 24, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Key changed/added classes in this PR

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishekagarwal87 Jun 27, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jihoonson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

abhishekagarwal87 commented Jun 24, 2021 •

edited

Loading

abhishekagarwal87 Jun 27, 2021 •

edited

Loading