Hi, May be I am a little bit late with my thoughts about a command syntax. How do I see it is going to be used: 1. A user is able to kill a query by unique id belonging only to this query. 2. A user is able to kill all queries started by a specific node. For killing a single query we must identify it by unique id which is going to be received directly from Ignite (e.g. running queries view) and not calculated by user. Internally the id is compound but why cannot we convert it to opaque integer or string which hides real structure? E.g. base16String(concat(nodeOrder.toString(), ".", queryIdOnNode.toString())) The syntax could be KILL QUERY '123' or KILL QUERY WHERE queryId = '123' For killing all queries started by some node we need to use only node order (or id). It could be like KILL QUERY WHERE nodeOrder = 34. чт, 22 нояб. 2018 г. в 12:56, Denis Mekhanikov <[email protected]>: > > Actually, option with separate parameters was mentioned in another thread > http://apache-ignite-developers.2346864.n4.nabble.com/proposed-design-for-thin-client-SQL-management-and-monitoring-view-running-queries-and-kill-it-tp37713p38056.html > > Denis > > чт, 22 нояб. 2018 г. в 08:51, Vladimir Ozerov <[email protected]>: > > > Denis, > > > > Problems with separate parameters are explained above. > > > > чт, 22 нояб. 2018 г. в 3:23, Denis Magda <[email protected]>: > > > > > Vladimir, > > > > > > All of the alternatives are reminiscent of mathematical operations. Don't > > > look like a SQL command. What if we use a SQL approach introducing named > > > parameters: > > > > > > KILL QUERY query_id=10 [AND node_id=5] > > > > > > -- > > > Denis > > > > > > On Wed, Nov 21, 2018 at 4:11 AM Vladimir Ozerov <[email protected]> > > > wrote: > > > > > > > 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 Юрий <[email protected]> > > > 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 <[email protected]>: > > > > > > > > > > > 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 Юрий <[email protected]> > > > > > 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 < > > > [email protected] > > > > >: > > > > > > > > > > > > > > > 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 Юрий < > > > [email protected]> > > > > > > > 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 > > > > > > > > > > > > > >
-- Best regards, Ivan Pavlukhin
