[jira] [Updated] (DRILL-5897) Support Query Cancellation when WebConnection is closed on client side both for authenticated and unauthenticated user's

["Sorabh Hamirwasia (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DRILL-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sorabh Hamirwasia updated DRILL-5897:
-------------------------------------
    Description: 
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)

  was:
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.


> 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: Task
>          Components: Web Server
>            Reporter: Sorabh Hamirwasia
>
> 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
(v6.4.14#64029)