Github user vrozov commented on a diff in the pull request:
https://github.com/apache/drill/pull/1113#discussion_r168599100
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/QueryStateProcessor.java
---
@@ -125,20 +125,17 @@ public void cancel() {
case PREPARING:
case PLANNING:
case ENQUEUED:
- moveToState(QueryState.CANCELLATION_REQUESTED, null);
- return;
-
case STARTING:
case RUNNING:
- addToEventQueue(QueryState.CANCELLATION_REQUESTED, null);
- return;
+ moveToState(QueryState.CANCELLATION_REQUESTED, null);
--- End diff --
1. Per my understanding, only during a transition from `STARTING` to
`RUNNING` it is necessary to delay the processing of `CANCELLATION_REQUESTED`
till requests are submitted to remote nodes for execution. Once the state is
transitioned to `RUNNING`, remote drillbits are ready to start processing
cancellation request, so no delay is necessary for the `RUNNING` state. In case
of `STARTING` there is already a call to `addToEventQueue()` inside
`QueryStateProcessor.starting()` that ensures that cancellation will be
processed after the transition.
1. I can't say why JIRA title states that it is a regression, as far as I
can tell, any delay in saving query profile may cause the issue. One
possibility is that the issue is amplified by
[DRILL-6053](https://issues.apache.org/jira/browse/DRILL-6053) that is a
regression caused by the fix for
[DRILL-4963](https://issues.apache.org/jira/browse/DRILL-4963) that introduces
even longer delay (due to synchronization).
---
