vrajat commented on issue #16060:
URL: https://github.com/apache/pinot/issues/16060#issuecomment-2980516085
TIL, in SSE there are two actions taken to interrupt. The code in watcher
task when it decides to cancel a query is:
```
if (shouldKill) {
maxUsageTuple._exceptionAtomicReference
.set(new RuntimeException(String.format(
" Query %s got killed because using %d bytes of memory
on %s: %s, exceeding the quota",
maxUsageTuple._queryId,
maxUsageTuple.getAllocatedBytes(), _instanceType, _instanceId)));
interruptRunnerThread(maxUsageTuple.getAnchorThread());
}
```
`_exceptionAtomicReference` is a field in the anchor thread's thread local.
Then as `InterruptedException` propogates, `exceptionAtomicReference !=
null` is the check for termination vs cancel. Example code from
InstanceResponseOperator.java
```
protected BaseResultsBlock getCombinedResults() {
try {
prefetchAll();
return _combineOperator.nextBlock();
} catch (EarlyTerminationException e) {
Exception killedErrorMsg =
Tracing.getThreadAccountant().getErrorStatus();
QueryErrorMessage errMsg =
QueryErrorMessage.safeMsg(QueryErrorCode.QUERY_CANCELLATION,
"Cancelled while combining results" + (killedErrorMsg == null ?
StringUtils.EMPTY : " " + killedErrorMsg));
return new ExceptionResultsBlock(errMsg);
} finally {
releaseAll();
}
}
```
IMO, the right way seems to be to propogate an extra piece of info on the
reason for termination/cancel. Maybe we should not try to shoe-horn the SSE
model onto MSE.
--
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]
