[
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)
