There are three different problems:
1. The client should not interrupt the http submit of the request since the outcome of interrupting an HTTP request or RMI is unpredictable (this is a client code issue
- the semantics of interrupt within Java are locally defined and there is no general protocol around how interrupt of NIO is handled).
2. Long running queries that do not return the first result until the query is done need to be cancelled before that result is ready.
3. There should be an easier way to cancel all queries associated with a UX page, especially when using the HA load balancer. In particular, there are an issues around how to cause queries to be cancelled that (A) are submitted concurrent with or immediately before the cancel of the queries for a page or that are being processed by the query optimizer by are not yet associated with IRunningQuery objects on the QueryEngine; or (B) would run to completion before returning their first result.
Currently, the application can associate a UUID with each query and issue a CANCEL with that UUID. There are two drawbacks with this approach.
- The application needs to track all in-flight queries.
- The CANCEL is effective as of when it is received by the QueryEngine. If the query is in an indeterminate state (for example, received by the REST API, but not yet an IRunningQuery), then it will not be cancelled.
Here is a list of some possibilities that could be explored for the cancellation of the submit of query that does not return any results until all work is done:
- Return http status code as early as possible so the client can terminate the submitted query. The servlet engine might not flush that status line through to the client in a timely basis unless we flush the response. However, flushing the response can hurt the performance of the servlet engine. This would need to be explored.
- REST redirect for long-running queries. This is a common pattern for long running operations. A client POSTs a request. The server responds with a redirect to a URL. The client follows the redirect to the URL using a GET and awaits the outcome of the process. Often, the client is given a means to interact with the computation, e.g., to cancel the process.