[
https://issues.apache.org/jira/browse/DRILL-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682081#comment-16682081
]
Kunal Khatua commented on DRILL-5897:
-------------------------------------
[~shamirwasia] if the challenge here is to handle query submissions
specifically from a WebUser , would it make sense to have the WebUser's browser
send a periodic ping / heartbeat (basically, a background async GET call) as a
signal to the Server to continue execution (for example, resetting a countdown
timer)?
We probably cant do this for REST submissions, because there isn't a simpler
way to manage the pings.
> Support Query Cancellation when WebConnection is closed on client side both
> for authenticated and unauthenticated user's
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: DRILL-5897
> URL: https://issues.apache.org/jira/browse/DRILL-5897
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
> Reporter: Sorabh Hamirwasia
> Priority: Major
>
> Today there is no session created (using cookies) for unauthenticated WebUser
> whereas for authenticated user's session is created. Also when a user submits
> a query then we wait until entire results is gathered on WebServer side and
> then send the entire Webpage in the response (probably that's how ftl works).
> For authenticated user's we only cancel the queries in-flight when the
> session is invalidated (either by timeout or logout). However in absence of
> session we do nothing for unauthenticated user's so once a query is submitted
> it will run until it's failed or successful. The only way to explicitly
> cancel a query is from profile page which will not work when profiles are
> disabled.
> We should research more on if it's possible to get the underlying
> WebConnection (not session) close event and cancel queries running as part of
> that connection close event. Also since today we will wait for entire query
> to finish on backend server and then send the response back, which is when a
> bad connection is detected it doesn't makes sense to cancel at that point
> (there is 1:1 mapping between request and connection) since query is already
> completed. Instead we can send header followed by batches of data
> (pagination) then we can detect early enough if connection is valid or not
> and cancel the query in response to that. More research is needed in this
> area along with knowledge of Jetty on how this can be achieved to make our
> WebServer more performant.
> It would also be good to explore if we can provide sessions for
> unauthenticated user connection too based on timeout and then handle the
> query cancellation as part of session timeout. This will also impact the way
> we support impersonation without authentication scenario where we ask user to
> input query user name for each request. If we support session then username
> should be done at session level rather than per request level which can be
> achieved by logging user without password (similar to authentication flow)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
