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