Generally with cancel the behavior should be (a) send a message to the underlying system to cancel, (b) return control to the user. Remember, cancel always occurs on a different thread than the one which is executing the query (usually calling ResultSet.next()). So implementing the cancel involves “cutting” a blocking wait of some kind. Very similar mechanism to timeout.
The underlying system may take a few seconds to cancel (or longer… it’s best effort). In a multi-hop system (say avatica thin client —> avatica server —> phoenix) there are multiple arrows to “cut”. We would definitely need a Cancel comment (CancelRequest). Remember that the Cancel command will likely arrive while an Execute or Fetch is in progress. Julian > On Jun 27, 2016, at 4:04 PM, Josh Elser <[email protected]> wrote: > > +1 for lifting this up to AvaticaResultSet > > Would be good for Avatica clients to have the standard means to cancel a > query (not hoping the Avatica server would ever get into a case where it's > not responding in a reasonable amount of time). > > Julian Hyde wrote: >> I am developing a fix for >> https://issues.apache.org/jira/browse/CALCITE-1227<https://issues.apache.org/jira/browse/CALCITE-1227> >> in >> https://github.com/julianhyde/calcite/tree/1227-streaming-csv-table<https://github.com/julianhyde/calcite/tree/1227-streaming-csv-table>, >> building on Zhen Wang’s >> https://github.com/apache/calcite/pull/239<https://github.com/apache/calcite/pull/239>. >> I added a “cancelFlag” field to CalciteResultSet. Should this — and some >> mechanism for a running statement to find out whether it has been canceled — >> make its way up to AvaticaResultSet? >> >> Implementing cancel is a complicated issue, but this seems like a good start. >> >> Julian >> >>
