I have logged https://issues.apache.org/jira/browse/CALCITE-1301 <https://issues.apache.org/jira/browse/CALCITE-1301>.
> On Jun 27, 2016, at 5:13 PM, Julian Hyde <[email protected]> wrote: > > 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 >>> >>> >
