[
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 done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
