Resource Management related cleanup#14104
Conversation
d5e7a3e to
2079065
Compare
| @@ -174,6 +171,8 @@ public SqlQueryManager( | |||
|
|
|||
| this.clusterSizeMonitor = requireNonNull(clusterSizeMonitor, "clusterSizeMonitor is null"); | |||
wenleix
left a comment
There was a problem hiding this comment.
"Split out queued phase from QueryManager" LGTM compared with b846616
Note the removal of DistributedQueryRunner#getQueryInfo doesn't seem to be included in this PR?
(b846616#diff-179c18855b05981dabfa4d6e458f8695L418)
There was a problem hiding this comment.
Just double check: now slug is provided as a parameter, while in the old PR, slug is part of the path? (See b846616#diff-ef10213de38c18dc49c5303d7eea77a4R234)
There was a problem hiding this comment.
Yes, I saw from our commit history we did this because our HTTP logging seems to exclude query params from the logs.
There was a problem hiding this comment.
This is not just a rebase conflict, looks like all references to unboundedExecutorService (was: queryExecutor) should have been removed entirely.
There was a problem hiding this comment.
Didn't see "slugValid" related method in this commit? (see b846616#diff-d65ad4547dcbc09fc621ac2ceddce6cdR217)
There was a problem hiding this comment.
This is because we cherry picked this earlier in #13110
There was a problem hiding this comment.
Why change this to nextToken? :)
There was a problem hiding this comment.
This was supposed to happen in a later commit. Fixed it.
There was a problem hiding this comment.
Why is this needed? Why not simply Futures.nonCancellationPropagating()?
There was a problem hiding this comment.
Turns out it's a different semantic. An attempt to cancel this future has no effect, whereas cancelling the returned future from nonCancellationPropagating may be cancelled (however this will not be propagated to the inner future).
There was a problem hiding this comment.
Since PurgeQueriesRunnable is gone who's responsible for cleaning up the queries map?
There was a problem hiding this comment.
How about calling it notFound? badRequest implies 400 status.
There was a problem hiding this comment.
What I'll do is, because every method that calls this passes in NOT_FOUND for the status, is I'll hardcode that NOT_FOUND and rename to notFound.
There was a problem hiding this comment.
Is it possible to also export the number of active threads in BoundedExecutor? -- this has been an operation pain when we want to monitor when BoundedExecutor is full.
There was a problem hiding this comment.
BoundedExecutor does not expose the number of active threads, however the underlying executor itself does export itself as an MBean via ThreadPoolExecutorMBean
wenleix
left a comment
There was a problem hiding this comment.
The last two commits LGTM:
- "Fix result caching in protocol Query"
- "Simplify token management in protocol Query "
This is a really great catch. Thank you. |
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
The normal minimum worker requirement applied to all queries is sufficient to cover this case. Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
0262287 to
6a2c70c
Compare
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
resourceGroup is already required in QueryStateMachine Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
querySubmitter should never throw, but if it does fail the query immediately Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Previously, the cache was effectively disabled for the first result, so a retry on first request resulted in a 410 gone. Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com> Co-authored-by: Raghav Sethi <raghavsethi.rs@gmail.com>
Co-authored-by: Dain Sundstrom <dain@iq80.com>
|
Merged! Thanks for the contribution! 😃 😃 😃 |
Rebase of #12801