ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yury Gerzhedovich (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-10161) Be able to cancel any query by query id
Date Tue, 05 Mar 2019 12:40:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16784384#comment-16784384

Yury Gerzhedovich commented on IGNITE-10161:

[~vozerov], Thnaks for the detailed review.

I fix part code for part of you comments:

1) Agree. Fixed.

3) Fixed.

4) Fixed.

5) Fixed.

9) Fixed. Unfortunately we have few places with use approach which I used as example, seems
we need to fix all of such places to avoid copying such approach in the future.

10) Fixed.


For second part your comments I have objections or questions:

2) In any case we don't have guaranties that or response will be reflect real effect. First
of all, we shouldn't remove running queries by their id from RunningManager after receive
KILL request, because it should be done only when query will be really ended. If we will just
check that query with given id exist and still running we can have at least two situation
when next code execution will try cancel already finished query: we have two simultanious
KILL request, both of them check that query exist, after that we return success for ASYNC
mode, and both of them try to cancel the query. One of them either no one will cancel the
query, however we already returned success. Or we check that query exists but it finished
before start cancellation process. So I propose to rely on first check that query is running.

6) We should skill all unknown message, because it's TOPIC and we will receive messages which
shouldn't be processed here. WE have the same approach in other places.

7) Removed catching any error here. However I'm not fully sure.... On one hand we have cancellation
process which is Runnable and can throw any RuntimeException. In other hand we have hung initial
node, which await message with result of cancellation, in case node with running query will
not send response or not stopped. Also as I see we have approach with catch Throwable for
onMessage methods, seems we need to check it and rewrite to avoid such copy-paste in the future.

8) If be honestly I don't understand why we need to do anything here. Could you please clarify
it? May be I don't understand purpose and process for the onDisconnected method.

> Be able to cancel any query by query id
> ---------------------------------------
>                 Key: IGNITE-10161
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10161
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Yury Gerzhedovich
>            Assignee: Yury Gerzhedovich
>            Priority: Major
>              Labels: iep-29
>             Fix For: 2.8
>          Time Spent: 10m
>  Remaining Estimate: 0h
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY '<_query_id>' \{ASYNC}_*
> _ASYNC_ is optional parameter which return control immediately without waiting real cancellation
will be done.
> By default, without ASYNC parameter, the request is blocking untill cancellation is not
> Query should be canceled  together with its parts on all nodes. 

This message was sent by Atlassian JIRA

View raw message