Denis, Space is bad candidate because it is a whitespace. Without whitespaces we can have syntax without quotes at all. Any non-whitespace delimiter will work, though:
KILL QUERY 45.1 KILL QUERY 45-1 KILL QUERY 45:1 On Wed, Nov 21, 2018 at 3:06 PM Юрий <jury.gerzhedow...@gmail.com> wrote: > Denis, > > Let's consider parameter of KILL QUERY just a string with some query id, > without any meaning for user. User just need to get the id and pass as > parameter to KILL QUERY command. > > Even if query is distributed it have single query id from user perspective > and will killed on all nodes. User just need to known one global query id. > > How it can works. > 1)SELECT * from running_queries > result is > query_id | node_id > | sql | schema_name | connection_id | duration > 123.33 | e0a69cb8-a1a8-45f6-b84d-ead367a00000 | SELECT ... | ... > | 22 | 23456 > 333.31 | aaa6acb8-a4a5-42f6-f842-ead111b00020 | UPDATE... | ... > | 321 | 3467777 > 2) KILL QUERY '123.33' > > So, user need select query_id from running_queries view and use it for KILL > QUERY command. > > I hope it became clearer. > > > > ср, 21 нояб. 2018 г. в 02:11, Denis Magda <dma...@apache.org>: > > > Folks, > > > > The decimal syntax is really odd - KILL QUERY > > '[node_order].[query_counter]' > > > > Confusing, let's use a space to separate parameters. > > > > Also, what if I want to halt a specific query with certain ID? Don't know > > the node number, just know that the query is distributed and runs across > > several machines. Sounds like the syntax still should consider > > [node_order/id] as an optional parameter. > > > > Probably, if you explain to me how an end user will use this command from > > the very beginning (how do I look for a query id and node id, etc) then > the > > things get clearer. > > > > -- > > Denis > > > > On Tue, Nov 20, 2018 at 1:03 AM Юрий <jury.gerzhedow...@gmail.com> > wrote: > > > > > Hi Vladimir, > > > > > > Thanks for your suggestion to use MANAGEMENT_POOL for processing > > > cancellation requests. > > > > > > About your questions. > > > 1) I'm going to implements SQL view to provide list of running queries. > > The > > > SQL VIEW has been a little bit discussed earlier. Proposed name is > > > *running_queries* with following columns: query_id, node_id, sql, > > > schema_name, connection_id, duration. Currently most of the information > > can > > > be retrieved through cache API, however it doesn't matter, any case we > > > need to expose SQL VIEW. Seem's you are right - the part should be > > > implemented firstly. > > > 2) Fully agree that we need to support all kind of SQL queries > > > (SLECT/DML/DDL, transactional, non transnational, local, distributed). > I > > > definitely sure that it will possible for all of above, however I'm not > > > sure about DDL - need to investigate it deeper. Also need to understand > > > that canceled DML operation can lead to partially updated data for non > > > transational caches. > > > > > > > > > > > > пн, 19 нояб. 2018 г. в 19:17, Vladimir Ozerov <voze...@gridgain.com>: > > > > > > > Hi Yuriy, > > > > > > > > I think we can use MANAGEMENT_POOL for this. It is already used for > > some > > > > internal Ignite tasks, and it appears to be a good candidate to > process > > > > cancel requests. > > > > > > > > But there are several things which are not clear enough for me at the > > > > moment: > > > > 1) How user is going to get the list of running queries in the first > > > place? > > > > Do we already have any SQL commands/views to get this information? > > > > 2) We need to ensure that KILL command will be processed properly by > > all > > > > kinds of SQL queries - SELECT/DML/DDL, non-transactional or > > > transactional, > > > > local queries and distributed queries. Will we be able to support all > > > these > > > > modes? > > > > > > > > Vladimir. > > > > > > > > On Mon, Nov 19, 2018 at 6:37 PM Юрий <jury.gerzhedow...@gmail.com> > > > wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > Earlier we agreed about syntax KILL QUERY > > > '[node_order].[query_counter]', > > > > > e.g. KILL QUERY '25.123' for single query or KILL QUERY '25.*' for > > all > > > > > queries on the node. Which is part of IEP-29 > > > > > < > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring > > > > > > > > > > > . > > > > > > > > > > Now I want to discuss internal realization of KILL query feature. > > > > > > > > > > My current vision is following: > > > > > After parsing, Ignite create KILL query command with two > parameters: > > > > > nodeOrderId, nodeQryId. To determine that need to kill all queries > > on a > > > > > node we can use negative value of query id, due to qry id always > have > > > > > positive values. > > > > > The command process at IgniteH2Indexing as native command. > > > > > By nodeOrderId we find node which initial for the query and send to > > the > > > > > node new GridQueryKillRequest with nodeQryId to TOPIC_QUERY with > not > > > > QUERY > > > > > POOL executor. > > > > > At GridReduceQueryExecutor we add support of processing new > > > > > GridQueryKillRequest > > > > > which just run already exists cancelQueries method with given qryId > > or > > > > with > > > > > all qryIds which currently running at the node in case at initial > > KILL > > > > > QUERY parameters used star symbol. > > > > > > > > > > I have a doubt which of thread pool we should use to process > > > > > GridQueryKillRequest. > > > > > My opinion it shouldn't be QUERY pool, due to the pool can be fully > > > used > > > > by > > > > > executing queries, it such case we can't cancel query immediately. > > May > > > we > > > > > use one of already existed pool or create new one? Or may be I'm > > > mistaken > > > > > and it should use QUERY pool. > > > > > > > > > > What do you think about proposed plan of implementation? > > > > > > > > > > And please give comments about which of thread pool will be better > to > > > use > > > > > for kill query requests. It's small, but really important part of > the > > > > > realization. > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > -- > > > > > Живи с улыбкой! :D > > > > > > > > > > > > > > > > > > -- > > > Живи с улыбкой! :D > > > > > > > > -- > Живи с улыбкой! :D >
